This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][InsertVSETVLI] Reverse traversal order of block in post pass [nfc]
ClosedPublic

Authored by reames on Dec 12 2022, 12:52 PM.

Details

Summary

This unblocks a following change to be more sophisticated during post pass rewriting.

Review wise, I basically just want a second set of eyes. This change should be straight forward, but since it took me an embarrassing number of attempts to get make check to pass. Let's make sure I'm not missing yet another cornercase.

Diff Detail

Event Timeline

reames created this revision.Dec 12 2022, 12:52 PM
reames requested review of this revision.Dec 12 2022, 12:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 12 2022, 12:52 PM
Herald added subscribers: eopXD, MaskRay. · View Herald Transcript

The phrase "block traversal" made me think you were changing the order we were visiting blocks. Which of course makes no sense for the local pass. Maybe "instruction traversal" would be better?

craig.topper added inline comments.Dec 12 2022, 1:16 PM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1244

Why is NextMI relevant to whether this instruction can be removed?

reames retitled this revision from [RISCV]{InsertVSETVLI] Reverse order of block traversal in post pass [nfc] to [RISCV]{InsertVSETVLI] Reverse traversal order of block in post pass [nfc].Dec 12 2022, 1:49 PM

The phrase "block traversal" made me think you were changing the order we were visiting blocks. Which of course makes no sense for the local pass. Maybe "instruction traversal" would be better?

Does the reworded title clarify?

llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1244

This is one of the generalizations planned.

The basic idea here is we need to merge the demanded fields with the differences between the two vsetvlis to figure out if we can validly rewrite the former. i.e. if tail policy is demanded, but the two differ, we can't rewrite the former, and thus can't remove the later.

The case that's a bit tricky is when the following vsetvli either a) reads VL (via the preserving form), or b) reads a GPR which is defined between the two instructions. The former should be handled by the implicit read when we visit NextMI being modeled in the Used set. The later requires some care, and the current code uses this routine to be conservative around that case.

This revision is now accepted and ready to land.Dec 12 2022, 2:53 PM
frasercrmck retitled this revision from [RISCV]{InsertVSETVLI] Reverse traversal order of block in post pass [nfc] to [RISCV][InsertVSETVLI] Reverse traversal order of block in post pass [nfc].Dec 13 2022, 1:49 AM
nemanjai added inline comments.
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1230

This causes failures with -Werror:

RISCVInsertVSETVLI.cpp:1230:27: error: 'iterator_range' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
  for (MachineInstr &MI : iterator_range(MBB.rbegin(), MBB.rend())) {
                          ^
/home/nemanjai/llvm/Git/trunk1/llvm-project/llvm/include/llvm/ADT/iterator_range.h:30:7: note: add a deduction guide to suppress this warning
class iterator_range {
      ^
1 error generated.

Example: https://lab.llvm.org/buildbot/#/builders/36/builds/28344

reames added inline comments.Dec 13 2022, 10:17 AM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1230

I have no idea what that warning means. Forming an iterator range from two iterators is pretty much the canonical use case. I'm happy to adjust code to remove the warning, but I'll need a hint on how to do so.

craig.topper added inline comments.Dec 13 2022, 10:22 AM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1230

I think you want make_range instead of iterator_range?

reames added inline comments.Dec 13 2022, 11:04 AM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1230

I absolutely do. Wow, how did that even compile, much less pass all the unit tests? Eek.

Fix upcoming shortly.

reames added inline comments.Dec 13 2022, 11:19 AM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
1230

Jordan beat me to a fix in 4f9d069, but I went ahead and switched to make_range in 3a020527 for clarity sake.