| Issue |
179010
|
| Summary |
Data layout strings don't capture scalable vector alignment
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
workingjubilee
|
LLVM does not require that a scalable vector's multiplicand is equal to a given fixed vector size in a target's data layout. Yet the alignment obviously must not *vary* based on the scalable vector's `vscale` multiplier, as that wouldn't be very... er... scalable. Yet, existing targets have surface-language types for scalable vectors which reflect layout constraints that aren't captured in LLVM's way of specifying data layout.
I am mostly thinking of AArch64 here: the predicate vector type, AKA `svbool_t`, apparently has an alignment of 2 (in bytes, so 16 bits)? That's fine by me, but I can't find that in the data layout strings for aarch64 targets.
I *could* assume that other scalable vectors on AArch64, as they are intended to use a multiplicand that is 16-byte-sized, use a 16-byte alignment. That's because [the LangRef says](https://llvm.org/docs/LangRef.html#data-layout) the default data layout, unless specified, is `"e-p:64:64:64-S0-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a:0:64"`. This could, at least, conceivably cover all RISCV vectors, as their multiplicand is apparently always supposed to be 8 (i.e. from `<vscale x 1 x i64>` to `<vscale x 8 x i8>`).
This information can be *slightly* important for frontends concerned with generating compatible code with *other* frontends. While they can conceivably hand-reimplement whatever rule is in play, it's much better if they can just use what LLVM knows.
Possible solutions:
- Specify `vscale`d vectors have the same alignment as the same vector without `vscale`, and add `-v16:16:16` to AArch64's data layouts (elegant, but conceivably something an ISA could disagree with).
- Add an explicit alignment "field" to data layout strings for vscaled vectors and specify this for AArch64 and RISCV targets (most compatible, albeit with the most busywork).
- Specify the alignment of the multiplicand must be exactly equal to size, essentially hardcoding the current values (likely to become incorrect, but hey, if it works).
- Demand everyone hand-reimplement whatever architecture-specific rules are in play... and then actually specify the alignment rules for SVE and RVV.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
