This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Remove custom zext/sext legalization code.
ClosedPublic

Authored by fhahn on Mar 26 2021, 12:57 PM.

Details

Summary

Currently performExtendCombine assumes that the src-element bitwidth * 2
is a valid MVT. But this is not the case for i1 and it causes a crash on
the v64i1 test cases added in this patch.

It turns out that this code appears to not be needed; the same patterns are
handled by other code and we end up with the same results, even without the
custom lowering. I also added additional test cases in a50037aaa6d5df.

Let's just remove the unneeded code.

Diff Detail

Event Timeline

fhahn created this revision.Mar 26 2021, 12:57 PM
fhahn requested review of this revision.Mar 26 2021, 12:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2021, 12:57 PM

Should we just be bailing on i1 src types? Otherwise if someone adds an i2 type it would just start to fail again.

fhahn updated this revision to Diff 333732.Mar 28 2021, 12:02 PM

Should we just be bailing on i1 src types? Otherwise if someone adds an i2 type it would just start to fail again.

That's a good point, thanks! I realized that my comment was a bit mis-leading, the code was not actually checking for a legal type. I updated it to use TLI.isTypeLegal, to check if the widened source type is legal. I think if it is legal, then using it to build a vector should also be legal? I added an assertion to make that clearer.

I am not sure if you should directly check for i1 src types, because that would mean we miss other combinations that cause crashes in this function (e.g. sext <1 x i64> %x to <1 x i128>) which is caught be the legal type check. Alternatively we could explicitly check for element types that are valid for vectors?

I am not sure if you should directly check for i1 src types, because that would mean we miss other combinations that cause crashes in this function (e.g. sext <1 x i64> %x to <1 x i128>) which is caught be the legal type check. Alternatively we could explicitly check for element types that are valid for vectors?

i8 on it's own isn't a legal type, neither is i16.

Umm. Do we actually need this code? If so for what?

llvm/test/CodeGen/AArch64/arm64-subvector-extend.ll
192

This looks odd, with the lanes being interchanged. I presume there's a lot of other code that converts the i1 vector over a call into vectors, and that doesn't preserve the register order?

fhahn updated this revision to Diff 333934.Mar 29 2021, 11:03 AM

I am not sure if you should directly check for i1 src types, because that would mean we miss other combinations that cause crashes in this function (e.g. sext <1 x i64> %x to <1 x i128>) which is caught be the legal type check. Alternatively we could explicitly check for element types that are valid for vectors?

i8 on it's own isn't a legal type, neither is i16.

Yeah, that might be a bit too restrictive. I think the original version (just checking if the MVT is valid/simple) should be enough, because my main concern is avoiding the crash.

Umm. Do we actually need this code? If so for what?

I added a few additional test cases (a50037aaa6d5) and it appears that while we have a bunch of tests that exercise the code, we get the same code without this combine. I updated the patch to remove it.

dmgreen accepted this revision.Mar 29 2021, 11:12 AM

Yeah. None of the tests I ran produced different code either. They appear to lowered differently, but end up with identical codegen.

If we find any cases where that isn't true, we can always bring the code back. LGTM. Thanks!

This revision is now accepted and ready to land.Mar 29 2021, 11:12 AM
fhahn retitled this revision from [AArch64] Fix lowering zext/sext of v64i1. to [AArch64] Remove custom zext/sext legalization code..Mar 29 2021, 11:40 AM
fhahn edited the summary of this revision. (Show Details)
This revision was automatically updated to reflect the committed changes.