This is an archive of the discontinued LLVM Phabricator instance.

Cleanup Chain Handling in X86ISelLowering
AbandonedPublic

Authored by niravd on Mar 31 2016, 12:05 PM.

Details

Reviewers
spatel
RKSimon
Summary

Previously only users of the first merged load's chain were merged which
potentially allows the merged load to elided from the chain of nodes
chained off of another of the merged loads.

Diff Detail

Event Timeline

niravd updated this revision to Diff 52256.Mar 31 2016, 12:05 PM
niravd retitled this revision from to Cleanup Chain Handling in X86ISelLowering.
niravd added reviewers: RKSimon, spatel.
niravd updated this object.
niravd added a subscriber: llvm-commits.
spatel edited edge metadata.Apr 1 2016, 9:39 AM

Can you expose the change in a test case?

This looks wrong, as it's losing the *original* load from the chain now.

Uses of any of the original chain outputs should be modified to depend on BOTH the original load, and the new load (through a TokenFactor), because I don't believe we are actually necessarily removing the original load during these transforms. That is, I think the original code was correct and necessary, as far as it went -- the issue was only that it failed to do the exact same thing for the output chains of any but the first load.

Also, please reference the PR for this.

Uses of any of the original chain outputs should be modified to depend on BOTH the original load, and the new load (through a TokenFactor), because I don't believe we are actually necessarily removing the original load during these transforms. That is, I think the original code was correct and necessary, as far as it went -- the issue was only that it failed to do the exact same thing for the output chains of any but the first load.

Right. Since it's duplicated there's no reason to expect them to be evaluated the same, but this would drop any WAR hazard on those just loads.

RKSimon edited edge metadata.Apr 26 2016, 11:20 AM

Is this PR10114?

Nirav are you still looking at this? We just got stung by a similar problem in broadcasts (D25039).

@niravd Whatever happened to this patch?

@niravd Abandon now that D38547 has landed?

niravd abandoned this revision.Nov 6 2017, 7:13 AM

Already handled in D38547