Change:
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.

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