Legal scalable predicate vectors (legal in the LLVM sense), e.g.
`vector<[16]xi1>` (or `<vscale x 16 x i1>`, using LLVM syntax) ought to
have alignment **2** rather than **16**, see e.g. [1].
MLIR currently computes the vector “size in bits” as:
```cpp
vecType.getNumElements()
* dataLayout.getTypeSize(vecType.getElementType()) * 8
```
but `getTypeSize()` returns a size in *bytes* (rounded up from bits), so
for `i1` it returns 1. Multiplying by 8 converts that storage byte back to 8
bits per element, which overestimates predicate vector sizes.
Instead, use:
```cpp
vecType.getNumElements()
* dataLayout.getTypeSizeInBits(vecType.getElementType())
```
For `vector<[16]xi1>` this changes:
* [before]: `alignment = 16 * (1 byte * 8) (i.e. `128 bits`),
to:
* [after]: `alignment = 16 * 1 bit` (i.e. `16 bits`).
This is a very small update that, based on the available tests, only
affects types like `vector<[16]xi1>`. It aligns MLIR with LLVM, making
sure that the corresponding alignment is 2 rather that 16. For context,
LLVM computes the alignment in this case via `getTypeStoreSize`, which
for `16 x i1` returns 2 bytes. Perhaps MLIR should follow similar path
in the future.
[1] https://developer.arm.com/documentation/ddi0602/2025-12/SVE-Instructions/LDR--predicate---Load-predicate-register-?lang=en
f9423ed07c