Page MenuHomePhabricator

[ARM] Make v2i1 a valid type for the MVE predicate register.
Needs ReviewPublic

Authored by simon_tatham on Aug 8 2019, 2:23 AM.

Details

Reviewers
samparker
dmgreen
Summary

There are MVE instructions that treat a 128-bit vector register as a
vector of two 64-bit lanes, e.g. the VLDRD.64 gather loads. To
represent predicated forms of those instructions usefully in code
generation, we'll want to use a v2i1 as the representation of the
predicate mask, because it only has one meaningful bit per 64-bit
lane.

Event Timeline

simon_tatham created this revision.Aug 8 2019, 2:23 AM

Some codegen tests would be good.

Yeah... A lot of the predicate code was written with the assumption that a v2i1 would not be a legal type. (Not deliberately, I just didn't think of it at all. We don't have the compares to make it generally useful). I'll have to at least run some fuzzer tests on this.

I'm surprised a lot of the existing v2i64 tests don't complain in some way.

Hmm. I may have underestimated the difficulty, then! My thought was that all I really needed was to arrange that if you already had a v2i1, you could use it as the predicate operand for one of the 64-bit-lane instructions and not have instruction selection fail, and perhaps if you already had a pair of them you could do bitwise ops between them just like you can with all the others.

I can write some simple codegen tests for the things I've just mentioned, but it sounds as if there are more complicated things I've overlooked that will also need testing?

It was the "buildvector" code from D65052 that I was thinking of the most (or "buildvector" is what I've been calling it at least). How to get values into and out of v2i1 vectors, how to handle shuffles of i1's vectors, sign extending a v2i1 to a v2i64, that kind of thing. The vectoriser will produce a lot of <2 x i1>'s in all kinds of weird and wonderful ways that we need to handle at least sensibly (if not always super efficiently, that's what cost models are for!).