Introduces the InstrInfo::areMemAccessesTriviallyDisjoint hook.
The test could check for instruction reorderings, but to avoid being brittle it just checks instruction dependencies.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/RISCV/disjoint.ll | ||
---|---|---|
27 ↗ | (On Diff #218723) | This test seems really brittle. Now that you've implemented the hook, the compiler can see that this load and store do not interact, so can now schedule the store after the load. However, what the hook actually means for these instructions is that the load and store don't interact, and so any more-specific schedule could undo this change by implementing a schedule that thinks if you do the store first, the code is faster. I don't know how to write a test that's less brittle to this kind of issue. I suppose a lot of asm tests could be changed by a change in the schedule, but it seems like this one has a large chance of suddenly not testing anything. Do you have any better ideas for how to test this, or do we not have enough testcases that hit the hook and are trivially disjoint? |
Rebased the test on master.
Changed the test to instead check the instruction dependencies directly.
Updated summary.
llvm/test/CodeGen/RISCV/disjoint.ll | ||
---|---|---|
6 ↗ | (On Diff #223817) | Please can you write a few sentences explaining how this tests that these two SW's are disjoint? I presume it's to do with the fact that the scheduler does not deem the SW %1:gpr, %0:gpr, 8 to have to come after the first SW (it not being in the successors list). Knowing how this tests the disjoint hook will help us understand how to update the test if the exact output ever changes. |
llvm/test/CodeGen/RISCV/disjoint.ll | ||
---|---|---|
27 ↗ | (On Diff #218723) | You're right, this merited some context and explanation. Thanks! |