This is an archive of the discontinued LLVM Phabricator instance.

[GISelKnownBits] Add support for PHIs
ClosedPublic

Authored by qcolombet on Jan 23 2020, 5:53 PM.

Details

Summary

Teach the GISelKnowBits analysis how to deal with PHI operations.
PHIs are essentially COPYs happening on edges, so we can just reuse the code for COPY.

This change would be NFC COPY-wise if we have left Depth untouched when calling computeKnownBitsImpl, like it was for COPYs.
This change is however required for PHIs as they may loop back to themselves and we would end up in an infinite loop.

We could make the change truly NFC for the COPYs by increasing Depth only for PHIs, but generally speaking I am not a fan of not increasing Depth or doing specially cases for COPYs.

Diff Detail

Event Timeline

qcolombet created this revision.Jan 23 2020, 5:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 23 2020, 5:53 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
qcolombet marked an inline comment as done.Jan 23 2020, 5:56 PM
qcolombet added inline comments.
llvm/unittests/CodeGen/GlobalISel/GISelMITest.h
111

In case someone wonders, this change is required to have MIRString with basic blocks that have variables that are live out, otherwise the machine verifier will complain that some variables are not live out of the predecessors when use in a phi.
(Basically we need the tracksRegLiveness property and when we set it, we need to mark as live ins all phys regs that are used across all the GISel tests.)

arsenm added a subscriber: arsenm.Jan 23 2020, 6:17 PM

I do think copies should be ignored for depth. Other places generally try to treat intervening copies as irrelevant. For example the MIRBuilder inserts copies where they aren't actually necessary when inserting a cast that turns out to be a no-op. I wouldn't want arbitrary changes like this to have an observable change on the final result

llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp
133

Typo registes

llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp
115

Register

I do think copies should be ignored for depth. Other places generally try to treat intervening copies as irrelevant

Fair enough. I still think we shouldn’t insert useless copies long term (those are not free).

qcolombet updated this revision to Diff 240223.Jan 24 2020, 9:06 AM
  • Fix typo in comment
  • Don't increase depth on COPYs
  • Use Register instead of unsigned in added unitests
qcolombet marked 2 inline comments as done.Jan 24 2020, 9:08 AM
arsenm accepted this revision.Jan 24 2020, 11:48 AM

LGTM

I do think copies should be ignored for depth. Other places generally try to treat intervening copies as irrelevant

Fair enough. I still think we shouldn’t insert useless copies long term (those are not free).

I agree. I looked at doing this, and it wasn't clear to me what guarantees the MachineIRBuilder should provide for the insert point. You could potentially want to write code that relied on an instruction definitely being inserted

This revision is now accepted and ready to land.Jan 24 2020, 11:48 AM

Thanks @arsenm for the review!

You could potentially want to write code that relied on an instruction definitely being inserted

As long as it doesn't need to be a new one, we could return the definition of the source.
But agree, some places actually expect that we produce a new register and that's not going to be an easy fix.

Thanks @arsenm for the review!

You could potentially want to write code that relied on an instruction definitely being inserted

As long as it doesn't need to be a new one, we could return the definition of the source.
But agree, some places actually expect that we produce a new register and that's not going to be an easy fix.

I'm not fond of the idea of doing something like:

MIB.setInsertPt(Insn);
MI = MIB.buildOp(...)

and having the builder silently ignore the explicitly setInsertPt. I think that behavior should be opt-in only to CSE, and obvious when it's being done.

This revision was automatically updated to reflect the committed changes.

and having the builder silently ignore the explicitly setInsertPt. I think that behavior should be opt-in only to CSE, and obvious when it's being done.

Fair, but do we really need to build something if a copy is what is going to be inserted?
I am assuming the answer would be a case by case answer.