Change:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.

Discussion:
CFG_GCCISH_PRE_LIB_FLAGS_arm-apple-darwin := CFG_GCCISH_POST_LIB_FLAGS_arm-apple-darwin := CFG_DEF_SUFFIX_arm-apple-darwin := .darwin.def <del> CFG_LLC_FLAGS_arm-apple-darwin := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-apple-darwin := </ins> CFG_INSTALL_NAME_arm-apple-darwin = -Wl,-install_name,@rpath/$(1) CFG_LIBUV_LINK_FLAGS_arm-apple-darwin = CFG_EXE_SUFFIX_arm-apple-darwin :=

CFG_GCCISH_PRE_LIB_FLAGS_arm-linux-androideabi := -Wl,-whole-archive CFG_GCCISH_POST_LIB_FLAGS_arm-linux-androideabi := -Wl,-no-whole-archive CFG_DEF_SUFFIX_arm-linux-androideabi := .android.def <del> CFG_LLC_FLAGS_arm-linux-androideabi := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-linux-androideabi := </ins> CFG_INSTALL_NAME_arm-linux-androideabi = CFG_LIBUV_LINK_FLAGS_arm-linux-androideabi = CFG_EXE_SUFFIX_arm-linux-androideabi :=

CFG_GCCISH_PRE_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-whole-archive CFG_GCCISH_POST_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-no-whole-archive CFG_DEF_SUFFIX_arm-unknown-linux-gnueabihf := .linux.def <del> CFG_LLC_FLAGS_arm-unknown-linux-gnueabihf := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-unknown-linux-gnueabihf := </ins> CFG_INSTALL_NAME_ar,-unknown-linux-gnueabihf = CFG_LIBUV_LINK_FLAGS_arm-unknown-linux-gnueabihf = CFG_EXE_SUFFIX_arm-unknown-linux-gnueabihf :=

llvm_c_strs.push(s); }; add("rustc"); // fake program name <del> add("-arm-enable-ehabi"); add("-arm-enable-ehabi-descriptors"); </del> if vectorize_loop { add("-vectorize-loops"); } if vectorize_slp  { add("-vectorize-slp");   } if sess.time_llvm_passes() { add("-time-passes"); }

<del> Subproject commit e1dabb48f0f898d1a808b3de3a26f5ee3735c7dd </del> <ins> Subproject commit f5f1ffea207b6b380127ff34f14015ae005d1413 </ins>

# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2014-01-27 </del> <ins> 2014-02-11 </ins>