https://reviews.llvm.org/D44785 changed the way adds, addus, subs, subus are handled. llvmpipe issues llvm.x86.sse2.padds and llvm.x86.sse2.psubs in src/gallium/auxiliary/gallivm/lp_bld_arit.c:lp_build_add() and lp_build_sub(). After D44785 landed, lp_test_blend.c started crash every time it entered LLVM-compiled code for type=u8nx16. Commenting out the issues of padds/psubs avoids this crash. The LLVM project, in discussing the bug at https://reviews.llvm.org/D44785, suspects that the cause may be because llvmpipe is "missing the autoupgrade stage"?
(In reply to Tom Hudson from comment #0) > https://reviews.llvm.org/D44785 changed the way adds, addus, subs, subus are > handled. > > llvmpipe issues llvm.x86.sse2.padds and llvm.x86.sse2.psubs in > src/gallium/auxiliary/gallivm/lp_bld_arit.c:lp_build_add() and > lp_build_sub(). > > After D44785 landed, lp_test_blend.c started crash every time it entered > LLVM-compiled code for type=u8nx16. > > Commenting out the issues of padds/psubs avoids this crash. The LLVM > project, in discussing the bug at https://reviews.llvm.org/D44785, suspects > that the cause may be because llvmpipe is "missing the autoupgrade stage"? Autoupgrade doesn't work for jit code (at least I wouldn't know how, and it never has in the past), so the way we handled disappearing of intrinsics in the past was to just not use them any more (for newer llvm versions) and do essentially the same as what autoupgrade would do, and we'll have to do the same here. I am however sure that in the past when intrinsics disappeared, it would complain when compiling the IR, rather than just call 0 function in the compiled code. Which is of course much nicer... For instance when the min/max (integer) intrinsics disappared: https://bugs.llvm.org/show_bug.cgi?id=28176 But I'm not sure if just calling 0 function now is expected due to some llvm changes, but if it is that's definitely making everybody's life harder...
FWIW I won't have time to look into this until next week, so volunteers welcome. Not using the intrinsics for new llvm version is trivial, but we need to update our existing code (when intrinsics can't be used) to match what the auto-upgrader would do, otherwise we'll probably get really crappy code (at least I suspect in this case llvm won't recognize our patterns), which is of course the reason why we used intrinsics in the first place... (Can't really say I'm all that happy to see the intrinsics go, as the code to emulate it is rather complex with 8 instructions, thus blowing up IR size and likely compile time as well, but I guess that's life when compilers getting smarter...)
*** Bug 107653 has been marked as a duplicate of this bug. ***
Fixed by 8e1be9a34ac8ce6f115eaf2ab0d99b6a0ce37630.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.