Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This fixes the issue I reported against D146872.
I investigated making MachinePointerInfo TypeSize aware but that felt wrong because MachinePointerInfo offsets are signed. In the end I've followed the approach used when splitting scalable vector storage ops and used a null MachinePointerInfo.
Whilst not specifically needed today (the LangRef only supports aggregate types that are either all fixed length or all scalable) perhaps the correct answer is for ComputeValueVTs to return StackOffsets, that way we're not a million miles away from supporting aggregate types that mix fixed length and scalable types. StackOffset being signed would then be a better (although not necessarily an easy) fit for MachinePointerInfo.
llvm/test/CodeGen/RISCV/rvv/undef-earlyclobber-chain.ll | ||
---|---|---|
2 ↗ | (On Diff #549926) | Why do we need to add +m, but have no other changes to the test? |
llvm/test/CodeGen/RISCV/rvv/undef-earlyclobber-chain.ll | ||
---|---|---|
2 ↗ | (On Diff #549926) | This test triggered a crash that reported the "m" extension is required for the requested operation. The code quality of vrgatherei16-subreg-liveness.ll was substantially worse after this fix with extra stack accesses and the like. I figured this was vscale mul related and so tried enabling the "m" extension and the original test output was obtained. I don't know enough to understand why but figured that an existing issue was being masked by the missing "offset is scaled" information. |
llvm/test/CodeGen/RISCV/rvv/undef-earlyclobber-chain.ll | ||
---|---|---|
2 ↗ | (On Diff #549926) | I took a look. Looks like we have a t2: i64 = vscale Constant:i64<0> that gets lowered to mul and then immediately converted to a libcall. I guess we should have a vscale combine for 0? |
llvm/test/CodeGen/RISCV/rvv/undef-earlyclobber-chain.ll | ||
---|---|---|
2 ↗ | (On Diff #549926) | Thanks for the investigation @craig.topper , I can confirm updating getVScale() removes the need for the +m test changes. If there's no objection I'll land it as part of this patch. |
I wasn't sure of the relative importance given the original work landed prior to LLVM 16. For AArch64 there's no significant need, I only discovered the bug due to some follow on work that I'm hoping to make public soon.
That said, I've just tried and the patches don't just cherry-pick so if you think this is something you're likely to hit for LLVM 17 just let me know and I'll try the branch route given I guess I'll need to learn how pull request work anyway :)