Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Try to reuse cleanup code when appropriate #300

Closed
marijnh opened this issue Mar 30, 2011 · 1 comment
Closed

Try to reuse cleanup code when appropriate #300

marijnh opened this issue Mar 30, 2011 · 1 comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@marijnh
Copy link
Contributor

marijnh commented Mar 30, 2011

Each ret, break. cont, and maybe others, currently outputs it own block-unwind-cleanup code. A block (or nested set of blocks) which requires non-trivial cleanup code, having a bunch of rets/breaks in it will cause way too much repetitive code to be generated. The compiler will eventually have to notice this situation and somehow centralize the cleanup code.
@brson
Copy link
Contributor

brson commented Oct 12, 2011

This problem has been greatly compounded by unwinding.

@brson brson mentioned this issue Oct 13, 2011
Closed
@ghost ghost assigned marijnh Feb 15, 2012
@marijnh marijnh removed their assignment Jun 16, 2014
oli-obk added a commit to oli-obk/rust that referenced this issue Sep 19, 2017
@oli-obk
Merge pull request rust-lang#300 from oli-obk/rustc_tests
dca1be6 
Get the test suite working inside the rustc test suite
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
@bors
Auto merge of rust-lang#300 - rrichardson:master, r=alexcrichton
bb4dabb 
added const SOCK_SEQPACKET,  and SOCK_RDM where applicable

... which is used for UNIX Seqpacket sockets as well as SCTP IP.

I have verified in source on  a couple Linux flavours as well as freebsd and darwin source that SOCK_SEQPACKET has value 5.
Solaris is the odd one with a value of 6.  I also added RDM for solaris (value 5)
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
@alexcrichton
Don't distinguish between i586/i686 (rust-lang#301)
a381482 
This was historically done as the contents of the `i686` module wouldn't
actually compile on i586 for various reasons. I believe I've tracked this down
to rust-lang#300 where LLVM refuses to compile a function using the `x86_mmx` type
without actually enabling the `mmx` feature (sort of reasonably so!). This
commit will now compile in both the `i586` and `i686` modules of this crate into
the `i586-unknown-linux-gnu` target, and the relevant functions now also enable
the `mmx` feature if they're using the `__m64` type.

I believe this is uncovering a more widespread problem where the `__m64` isn't
usable outside the context of `mmx`-enabled functions. The i686 and x86_64
targets have this feature enabled by default which is why it's worked there, but
they're not enabled for the i586 target. We'll probably want to consider this
when stabilizing!
ZuseZ4 pushed a commit to EnzymeAD/rust that referenced this issue Mar 7, 2023
@tgymnich
ForwardMode IntrinsicInst (rust-lang#300)
c7bc24c 
* implement intrinsicInst

* add tests
workingjubilee pushed a commit to workingjubilee/rustc that referenced this issue May 10, 2023
@programmerjake
Merge pull request rust-lang#300 from programmerjake/all_lane_counts
d5cd4a8 
add all_lane_counts feature to enable non-power-of-2 lane counts <= 64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@marijnh @brson