This is an archive of the discontinued LLVM Phabricator instance.

[MemoryDependenceAnalysis] Support -analyze
AbandonedPublic

Authored by anemet on May 7 2015, 12:55 AM.

Details

Reviewers
reames
hfinkel
Summary

I was trying to debug a missed Load-PRE optimization (see the testcase)
and found that there was no convenient way to do this. This
adds -analyze support to memdep and a testcase which demonstrates a
trick to do this in case one wants non-local dependence analysis (like
GVN).

Admittedly, this is pretty non-local dep focused right now but it's
certainly better that what we have currently.

Diff Detail

Event Timeline

anemet updated this revision to Diff 25140.May 7 2015, 12:55 AM
anemet retitled this revision from to [MemoryDependenceAnalysis] Support -analyze.
anemet updated this object.
anemet edited the test plan for this revision. (Show Details)
anemet added reviewers: hfinkel, reames.
anemet added a subscriber: Unknown Object (MLST).
reames edited edge metadata.May 12 2015, 2:07 PM

I believe that we have a MemDepPrinter class. How is this different?

anemet abandoned this revision.May 13 2015, 12:02 AM

Err ... it's not, thanks for pointing it out! I got misled by not seeing anything in the testsuite :(. I'll commit the test for -print-memdeps.

Any chance I could get you to either improve documentation or comments to save the next person the same mistake? Possibly the -analyze option could even be implement in terms of MemDepPrinter or vice versa?

As an aside, relying on MemoryDependence to give you inter-iteration
access dependence is ... not a great idea.
I know load-pre currently relies on this + PHITranslation hacks[1],
(and i've made memoryssa do it so new load pre can do it), PRE of loop
iterations like this is probably a problem that should be solved a
better way.

[1] PHITransAddr's logic to do gep simplification by looking for
things that have the same value (it literally does local value
numbering), and propagating constants through additions that appear
in PHI translated operations is pretty much a hack, and if you want to
get more cases, we shouldn't be piling on hacks.

(and i've made memoryssa do it so new load pre can do it), PRE of loop
iterations like this is probably a problem that should be solved a
better way.

Noted. I would also like this optimization to get improved by coupling it with memchecks. Probably a more loop-focused pass would work better.

Any chance I could get you to either improve documentation or comments to save the next person the same mistake? Possibly the -analyze option could even be implement in terms of MemDepPrinter or vice versa?

That was my intention too by keeping the testcase (that's where I looked initially) but sure let me see how far I can push this.