[PATCH] D45721: [X86] Lowering PACK*S (pack with saturation) intrinsics to native IR (LLVM side)

Roland Scheidegger via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 7 18:19:03 PDT 2018


sroland added a comment.

Hmm I suppose that's "more stuff which breaks our JIT compilation".
Removing these intrinsics actually is looking a bit ugly from my point of view (mesa llvmpipe developer).
One issue is that we take care to only emit instructions as necessary - that is if the packxxx instructions aren't available, we only do whatever is necessary to accomplish the pack - so if we already know we cannot have values outside the target range (or maybe we can have but we don't care for some reason) we make sure to only emit shuffle. But if packxxx is available we still prefer that of course.
And if we can't use intrinsics, we have to emit loads of other IR instructions (and they need to match what the autoupgrade would do), but still need a separate path for when we know the backend won't be able to use packxxx intrinsic, which is getting real ugly.

And I can only hope that whenever some other backend implements similar autoupgrade (pack instructions aren't exactly sse specific) they'll actually use the _same_ pattern for it, otherwise that's really going to get insane.

<rant mode on>
Removing intrinsics in general is quite a pain for us, because to actually still get usable (performance-wise) code we need to match what the auto-upgrader does manually exactly (and do some prayers the pattern isn't changed at some point). This is for instance apparent also with the change to remove the saturated adds/subs (which was reverted for now), where the pattern is rather complex (I bet it doesn't help compile times), and our fallback path was in fact using different instructions to emulate it (I'd rather wish there were llvm.add/subsat instructions instead, probably just about all cpus can actually do it natively...).
If there's some easy way to use autoupgrade for jit compilation, please enlighten me (although it's only viable if it has insignificant cost compared to rest of compilation), because my quick experiments weren't exactly successful...
<rant mode off>


https://reviews.llvm.org/D45721





More information about the llvm-commits mailing list