As noted by @reames, we should be checking that the memory access is aligned to
the element size (or the unaligned vector memory access feature is enabled)
before lowering vlseg/vsseg intrinsics via the interleaved access pass.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
llvm/test/CodeGen/RISCV/rvv/vector-interleave-store.ll | ||
---|---|---|
43 | Amusingly, this is still wrong by the alignment rule. "Implementations are allowed to raise a misaligned address exception on whole register loads and stores if the base address But this has nothing to do with the segment load/store lowering stuff. |
A heads up, I missed a change in the loop vectoriser test output and have committed the change here: b9af08629297410eabffb694526c0bbace1270fe
One of the interleaved access tests no longer seems to be unrolled. I'm not sure how alignment would affect unrolling here though.
llvm/test/CodeGen/RISCV/rvv/vector-interleave-store.ll | ||
---|---|---|
43 | I did a bit of investigating, and I think this might actually be ok after what Craig pointed out in D154739. vsNr.v always has EEW=8, since the MEW bit is 0 and width[2:0] is 0. Admittedly it took me a while to parse this from the spec. And that's what we test for in unaligned-loads-stores.ll anyway |
Amusingly, this is still wrong by the alignment rule.
"Implementations are allowed to raise a misaligned address exception on whole register loads and stores if the base address
is not naturally aligned to the larger of the size of the encoded EEW in bytes (EEW/8) or the implementation’s smallest
supported SEW size in bytes (SEW MIN /8)."
But this has nothing to do with the segment load/store lowering stuff.