gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0
authorRoland Scheidegger <sroland@vmware.com>
Thu, 23 Aug 2018 17:07:05 +0000 (19:07 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Fri, 24 Aug 2018 05:50:13 +0000 (07:50 +0200)
commit8e1be9a34ac8ce6f115eaf2ab0d99b6a0ce37630
tree77d4f401f3796349a64119ee280633d521669063
parent45b5f5fa25b844bab458369a50f7423724dc4283
gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0

These have been removed. Unfortunately auto-upgrade doesn't work for
jit. (Worse, it seems we don't get a compilation error anymore when
compiling the shader, rather llvm will just do a call to a null
function in the jitted shaders making it difficult to detect when
intrinsics vanish.)

Luckily the signed ones are still there, I helped convincing llvm
removing them is a bad idea for now, since while the unsigned ones have
sort of agreed-upon simplest patterns to replace them with, this is not
the case for the signed ones, and they require _significantly_ more
complex patterns - to the point that the recognition is IMHO probably
unlikely to ever work reliably in practice (due to other optimizations
interfering). (Even for the relatively trivial unsigned patterns, llvm
already added test cases where recognition doesn't work, unsaturated
add followed by saturated add may produce atrocious code.)
Nevertheless, it seems there's a serious quest to squash all
cpu-specific intrinsics going on, so I'd expect patches to nuke them as
well to resurface.

Adapt the existing fallback code to match the simple patterns llvm uses
and hope for the best. I've verified with lp_test_blend that it does
produce the expected saturated assembly instructions. Though our
cmp/select build helpers don't use boolean masks, but it doesn't seem
to interfere with llvm's ability to recognize the pattern.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106231
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/gallivm/lp_bld_arit.c