Change:
<del> Subproject commit 48818e9f5d0f2d5978a9b43ad1a2e8d0b83f6aa0 </del> <ins> Subproject commit 71fe7ec06b85f612fc0e4eb4134c7a7d0f23fac5 </ins>

Discussion:
The following piece of code fail when compiled to wasm32-unknown-unknown since nightly-2019-07-18. This nightly introduces so probably related. with configuration: see the repo: it contains: javascript file used to execute test with node. file to execute the test on rust version 2019-07-17 and 2019-07-18. probably introduced by if you remove either or it works (it is not failing anymore) cc
I changed an example a bit, minimized it from the size of wasm binary prespective and used some c-reduce (which hasn't yield much improvements). compiling with there is no notable difference in , only some identifiers and imm arg in e.g. which I believe is not related. The miscompilation seems to happen around function, specifically when copying low and high parts of the u128 by the out RVO ptr (): in miscompiled version we just do this (): which doesn't make a lot of sense since should hold i64 of descriminator of returned by . All this makes me think (although I am of course not sure) that this is a LLVM IR to wasm32 lowering bug, so cc
I haven't investigated this in detail yet, but in your analysis, in the reduced version, returns a plain , not a , so it makes sense that it's not storing the discriminator.
What I meant is that the descriminator of the returned by (which is , AFAIR) is stored in first half of the out ptr (which is the return value of as you noted) Or in other words, it attempts to squeeze the descriminator of into .
I think I've reduced this a bit further: generates: and it looks like the upper or lower bits (dunno which, but at least one) isn't being copied over I've opened an upstream bug at
Visiting for compiler triage meeting. I'm marking this as a "P-medium" bug since it is specific to WASM and also due to an LLVM bug. I'm not sure if we plan to fix this on our side in any way?
The reduced testcase is now fixed in .

This example fails when compiled with "haswell" or more recent: I bumped into this when compiling with and assumed it was related to , but after minimising the testcase I don't think it is. My next guess is an llvm bug but I thought I'd make an issue here in case anyone else bumps into it or wants to help investigate. I've created a self-contained godbolt: The two uses of unsafe I believe are sound. I think I've ruled out target-features being the cause, because this succeeds: Which should enable identical features to haswell given This occurs on nightly and stables back to 1.34.0, though 1.33.0 and prior seem to work correctly. Tested on Broadwell (Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz) and Skylake (Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz). Same issue filed against crate:
It would help tremendously if you could reduce that example further.
You can use C-Reduce to achieve that.
I'll look into using bugpoint and -opt-bisect-limit to narrow this down. Any other suggestions welcome. Thanks for the suggestion, I didn't know C-Reduce worked for Rust! My suspicion is in llvm's optimization passes, i.e. LLVM IR -assembly, so I'll give llvm's bugpoint a go first.
It works for pretty much any language. It just does changes like removing a line or changing it a bit, so it often generates invalid C as well. Only a few passes assume C, but those will just not reduce the test case for Rust. See
Unforunately, C-Reduce proved to be too clever when I ran it: it replaced: with While this is technically a 'minimization', it's not a very useful one.
Not sure if it helps, but revealed to be the first bad commit.
THe problem appears to be related to the function inside . For some reason, the high-order bit in (computed as ) seems to be getting left off. The earliest point at which this occurs appears to be the call . The correct result is , but with , it gets miscompiled somehow to return . Note that . Unfortunately, the problem disappeared when I made a standalone project with and .

I decided to give it a try and managed to simplify the code: Assembly output from 1.33.0 and 1.34.0 is identical, except for this block of AVX instructions: Looks like some of them got incorrectly optimized away. I'm not familiar with how LLVM vectorizes and optimizes things, so sadly this is as far as I can get on my own. Edit: Just to confirm, running with points to .
I managed to produce a smaller but slightly different reduction. I'm not sure if it also triggers the exact same issue reported here, but a similar asm diff is observed, see the diff in
Check-in from the compiler triage meeting: Summarizing, the previous comments, it seems we have and we have to a commit that . This looks likely to be an LLVM bug. I'm going to cc and in the hopes that one of them can help in pushing this to resolution. I'm marking it as P-high.
The IR for the functions is the same, so this is an issue in the backend, not the SLP vectorizer. It looks like LLVM correctly determines that one of the vpsrld's is dead based on demanded elements and replaces the packus with a pshufb. A little later we see: Which doesn't look right... pshuflw -28 is a no-op operation, but the previous pshufb is not. This combine is performed by matchUnaryPermuteShuffle(), but I haven't looked further than that yet.
LLVM bug:
Fixed & backported to LLVM 9.