This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG] Use TypeSize variant of ComputeValueVTs to compute correct offsets for scalable aggregate types.
ClosedPublic

Authored by paulwalker-arm on Aug 14 2023, 7:39 AM.

Diff Detail

Event Timeline

paulwalker-arm created this revision.Aug 14 2023, 7:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 14 2023, 7:39 AM
paulwalker-arm requested review of this revision.Aug 14 2023, 7:39 AM

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.

craig.topper added inline comments.Aug 14 2023, 9:35 AM
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?

paulwalker-arm added inline comments.Aug 14 2023, 9:41 AM
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.

craig.topper added inline comments.Aug 14 2023, 11:18 AM
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?

This revision is now accepted and ready to land.Aug 14 2023, 8:04 PM
paulwalker-arm added inline comments.Aug 15 2023, 3:19 AM
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.

Should we backport this to LLVM 17?

paulwalker-arm added a comment.EditedAug 17 2023, 4:42 AM

Should we backport this to LLVM 17?

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 :)

Should we backport this to LLVM 17?

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 :)

Wasn't the code added in March 2023? That would have been after LLVM 16 branched.

Should we backport this to LLVM 17?

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 :)

Wasn't the code added in March 2023? That would have been after LLVM 16 branched.

You're quite right, I somehow got confused with https://reviews.llvm.org/D94142.