This is an archive of the discontinued LLVM Phabricator instance.

[rs4gc] Simplify code by cloning existing instructions when inserting base chain [NFC]
ClosedPublic

Authored by reames on Mar 9 2021, 9:30 PM.

Details

Summary

This is nfc, but just complicated I wanted a separate set of eyes. The motivation is a) cleaner code, and b) reducing some spurious test changes in D98315.

Previously we created a new node, then filled in the pieces. Now, we clone the existing node, then change the respective fields. The only change in handling is with phis since we have to handle multiple incoming edges from the same block a bit differently.

Diff Detail

Event Timeline

reames created this revision.Mar 9 2021, 9:30 PM
reames requested review of this revision.Mar 9 2021, 9:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 9 2021, 9:30 PM

As I see the difference between old and new behavior is as follows:
Before we created new instruction which are not constructed yet (PHI node and verifier will complain if we missed anything) or are initialized with undefs.
Now we just create a new instructions containing the same values as derived pointer.

In both cases, later we fill the new instructions with detected bases. If there is not bugs the result should be the same.
In case we missed anything in the old case we get undef and with this patch we get old value.

If we take into account the patch https://reviews.llvm.org/D98315 which may skip setting second operand for ShuffleVector, with this patch
we can get the second operand equal to the old value instead of undef. I do not see how bad it can be but it is a difference.
So the main difference I see is related to ShuffleVector but not phi.

Not sure but original way seems a bit more protective than new one,
What kind of "some spurious test changes" do you observe?

Generally I do not have strong preference what is better, so I'm ok with this patch.

skatkov accepted this revision.Mar 15 2021, 8:02 PM
This revision is now accepted and ready to land.Mar 15 2021, 8:02 PM
This revision was landed with ongoing or failed builds.Mar 16 2021, 1:16 PM
This revision was automatically updated to reflect the committed changes.

< ...

So the main difference I see is related to ShuffleVector but not phi.

Not sure but original way seems a bit more protective than new one,
What kind of "some spurious test changes" do you observe?

For the phi case, the new pattern is actually safer. Consider the case where we miss an operand. With the old code, we'd have a syntactically valid phi node with the wrong input. With the new code, the verifier would reject the phi as it would be missing an operand.

You're right that (combined with the later change) the primary effect is reusing the second operand of the shuffle. It turns out I'd screwed up the diffs I'd posted. I'd posted that change *without* being rebased on this one. The diffs I'd been concerned about was the use of undef operands (as opposed to the original operand). What is very unclear to my now, is why I thought that was a bad thing. :)

I ended up landing this with a change to explicitly use undef for the second operand of a broadcast. That's entirely NFC, and frankly, looks cleaner to me now. Now sure what I was thinking when I first posted this.

For the phi case, the new pattern is actually safer. Consider the case where we miss an operand. With the old code, we'd have a syntactically valid phi node with the wrong input. With the new code, the verifier would reject the phi as it would be missing an operand.

May be I'm missing something but to me it looks opposite :)
In case some operand is missed, old code will produce incorrect phi node while new one will contain wrong input...

For the phi case, the new pattern is actually safer. Consider the case where we miss an operand. With the old code, we'd have a syntactically valid phi node with the wrong input. With the new code, the verifier would reject the phi as it would be missing an operand.

May be I'm missing something but to me it looks opposite :)
In case some operand is missed, old code will produce incorrect phi node while new one will contain wrong input...

The key difference is between setIncomingValue and addIncomingValue. If incorrect, the new code will fail to add an incoming edge. That will produce a PHI which immediately fails verification.