llvm dev - Dec 2021 - [RFC] Adding a new way of specifying vector alignments in DataLayout

Hi everybody,

TLDR: in https://reviews.llvm.org/D112531 I'm proposing a new style of
specifying vector alignments in the data layout string. I'd like to
open this up to the community and gather some feedback to ensure this
design satisfies as many architectures as possible, so that someone
doesn't have to come along in a couple of years to propose yet another
way!

As a brief bit of background, vector alignments are currently specified
in the DataLayout according to their total size in bits; for example,
v128:32:64 would specify all 128-bit vectors as being ABI aligned to 32
bits, but preferably to 64 bits.

This is an awkward fit for some architectures I've worked on --
including the RISC-V V extension (RVV) -- for a couple of reasons.

The first is that in these architectures, the requirements on alignment
are really to do with to their *element size*; v4i8 and v2i16 can be
aligned differently, for example. There's no natural way of specifying
this as it stands.

The second reason is that on variable-length vector architectures, at
least on RVV, we have potentially thousands of legal vector type sizes.
The maximum RVV vector register is 65536 bits and we have the ability
to combine 8 registers into even wider vectors. RVV is not even
theoretically limited to power-of-two legal vector types given we have
control over the active vector length. Writing all of these out using
total vector sizes alone is infeasible.

As such I was proposing that we add a new vector specification format:
"ve". This specifies alignment based on *element size*. For RVV we
could use these, e.g., "ve8:8-ve16:16-ve32:32-ve64:64" and this would
cover us for all possible vectors.

This format is mututally exclusive with the other "v" specifier to
avoid ruling on conflicts that would disadvantage one style of
architecture over another.

In the review thread, @nikic asked about whether we need to provide
support for differentiating between int and float elements. They also
asked whether any architectures' alignments depend on *both* element
size and total size.

I proposed we could extend "ve" in the future if required, though a
system of specializations: 

* vi/vf could specialize integer/floating-point element aligments
* vX[eif] could specialize total size (OR (min) number of elements?)

The precedence can be seen in "ve16:16-vf16:32-v32f16:64":
1. <2 x half> has 64-bit alignment
2. <N x half> (N != 2) has 32-bit alignment
3. <M x i16> (all M) has 16-bit alignment.

Are there any architectures out there that would require these
enhancements? Is there anything I've missed that would make some
target's life much easier?

Cheers,
Fraser Cormack