This is an archive of the discontinued LLVM Phabricator instance.

[GVN, OptDiag] Print the interesting instructions involved in missed load-elimination
ClosedPublic

Authored by anemet on Nov 9 2016, 9:22 PM.

Details

Summary

This includes the intervening store and the load that we're trying to
forward from in the optimization remark for the missed load elimination.

This is hooked up under a new mode in ORE that allows for compile-time
budges for a bit more analysis to print more insightful messages. This
mode is currently enabled for -fsave-optimization-record (-Rpass is
trickier since it is controlled in the front-end).

With this we can now print the red remark in http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L446

Diff Detail

Repository
rL LLVM

Event Timeline

anemet updated this revision to Diff 77444.Nov 9 2016, 9:22 PM
anemet retitled this revision from to [GVN, OptDiag] Print the interesting instructions involved in missed load-elimination.
anemet updated this object.
anemet added reviewers: hfinkel, dberlin.
anemet added a subscriber: llvm-commits.
anemet updated this revision to Diff 77840.Nov 14 2016, 10:47 AM

Rebase patch-set

hfinkel added inline comments.Nov 22 2016, 6:45 AM
lib/Transforms/Scalar/GVN.cpp
1217 ↗(On Diff #77840)

This iteration order is going to be non-deterministic if there are multiple users; I don't think we can do it this way. Plus, this won't really give the best answer. Unfortunately, actually giving the best answer probably needs to wait for MemorySSA/NewGVN (because looking at other pointer uses won't pick up cases where a smaller load is replaced by part of a larger store, etc.). In the mean time, can we do something deterministic (e.g. sort the other instructions by dominance, pick the last instruction in the last block (perhaps making use of OrderedBasicBlock))?

anemet added inline comments.Nov 28 2016, 3:33 PM
lib/Transforms/Scalar/GVN.cpp
1217 ↗(On Diff #77840)

Thanks, you're right. For now I just bail if there are more than one other users.

I expect this won't be effective so we will soon have to add the analysis you're suggesting.

anemet updated this revision to Diff 79467.Nov 28 2016, 3:34 PM

Only provide the "other" access if there is only one. This makes the result
deterministic.

hfinkel accepted this revision.Nov 28 2016, 3:51 PM
hfinkel edited edge metadata.

LGTM

This revision is now accepted and ready to land.Nov 28 2016, 3:51 PM
This revision was automatically updated to reflect the committed changes.