[llvm] [AArch64][GlobalISel] Expand abs.v4i8 to v4i16 and abs.v2s16 to v2s32 (PR #81231)

Amara Emerson via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 15 14:15:06 PDT 2024


aemerson wrote:

> > I think we should try to stick with extending elements because the legalizer's overall strategy is to rely on extending/truncating artifact operations to be eliminated. In that respect, vectors aren't too different from scalars, the overall type is too narrow for the operation to natively support, and therefore we perform the operation at the wider type and truncate back down to the original width. If the user instruction of that value also doesn't support that narrow type, it extends it and both truncate and extend are eliminated by the artifact combiner.
> > While this folding away can also be done for moreElements/fewerElements, if we start doing vector promotion we lose this symmetry of truncate/extend for both scalars and vectors. If there's serious problems with this approach that we can't mitigate then I'm open to changing my mind, but for now I agree with this change.
> 
> OK. I still don't think I agree that this is the best way to handle it and think this will lead to worse code, but we do the same thing for other operations already. There is a bug report in #81374 from recently.
> 
> I don't believe it is as easy to deal with vectors as it is for scalars (anyext/trunc cannot be treated as a nop), and vectors always need to handle odd vector types through MoreElements. As https://godbolt.org/z/nrc6553xq shows this has only really traded one place we fallback to another, more common one in practice. The issue isn't really in the abs, it's in us not handling sext/zext/anyext for vector types yet. Hopefully when we fix that we can revisit this, and like I said elsewhere in order to make everything optimal we might well need a combo of both methods.

Sorry I missed this reply. Having thought about it more I think you're right, using moreElements for vectors is going to be unavoidable and perhaps we should try to standard on that.

https://github.com/llvm/llvm-project/pull/81231


More information about the llvm-commits mailing list