This is an archive of the discontinued LLVM Phabricator instance.

[LICM] Add a diagnostic analysis for identifying alias information
ClosedPublic

Authored by anna on Aug 16 2018, 10:45 AM.

Details

Summary

Currently, in LICM, we use the alias set tracker to identify if the

instruction (we're interested in hoisting) aliases with instruction that
modifies that memory location.

This patch adds an LICM alias analysis diagnostic tool that checks the
mod ref info of the instruction we are interested in hoisting/sinking,
with every instruction in the loop.  Because of O(N^2) complexity this
is now only a diagnostic tool to show the limitation we have with the
alias set tracker and is OFF by default.

Test cases show the difference with the diagnostic analysis tool, where
we're able to hoist out loads and readonly + argmemonly calls from the
loop, where the alias set tracker analysis is not able to hoist these
instructions out.

Diff Detail

Repository
rL LLVM

Event Timeline

anna created this revision.Aug 16 2018, 10:45 AM
reames requested changes to this revision.Aug 16 2018, 11:13 AM

Detailed comments inline.

A couple of testing notes:

  1. don't the guard tests change output as well? Or has Max's fix for that already landed?
  2. we need some tests for readonly calls which are not guards or invariant.starts.
lib/Transforms/Scalar/LICM.cpp
1588 ↗(On Diff #161062)

I don't see any reason not to merge these two functions. They can both work on memory locations. The internal behaviour can be conditional. This also extends this to read only calls.

Unrelated, but it just occurred to me this interface could be simplified with MemoryLocation. Expect to have to rebase shortly. :)

1597 ↗(On Diff #161062)

Move to top of file

1601 ↗(On Diff #161062)

Comment doesn't seem consistent with this being only a diagnostic mechanism. I think you need to adjust either your submission comment or this comment to be consistent.

(For those reading along, this is a port of a downstream patch. The primary *upstream* value is for finding AST deficiencies, but we do run with a small non-zero value for this.)

1634 ↗(On Diff #161062)

You can lift the formation of the MemoryLocation out of this loop, and even out of the function.

This revision now requires changes to proceed.Aug 16 2018, 11:13 AM
anna added a comment.Aug 16 2018, 11:37 AM

Detailed comments inline.

A couple of testing notes:

  1. don't the guard tests change output as well? Or has Max's fix for that already landed?

I'd tested to see if changing the default value in this patch caused any other LICM test to fail, none did other than the invariant.start case. So, I guess Max's fix has landed for guards.

  1. we need some tests for readonly calls which are not guards or invariant.starts.

will do.

lib/Transforms/Scalar/LICM.cpp
1601 ↗(On Diff #161062)

Last part of the comment talks about the complexity, which is the reason for having it as a diagnostic tool (lines 1610 to 1612). I'll add the "diagnostic mechanism" phrase at the start of this comment as well.

anna marked 4 inline comments as done.Aug 16 2018, 2:09 PM
anna updated this revision to Diff 161106.Aug 16 2018, 2:11 PM

addressed review comments. added more tests. Diagnostic analysis used for loads and readonly+argmemonly calls.

reames accepted this revision.Aug 16 2018, 2:25 PM

LGTM

I still feel the framing comment could use some improvement, but I don't have anything specific I can suggest.

Fair warning, you've got a slightly messy rebase. We apparently miscommunicated and I landed the MemLoc refactor in the meantime.

This revision is now accepted and ready to land.Aug 16 2018, 2:25 PM
anna updated this revision to Diff 161227.Aug 17 2018, 6:32 AM

rebased over ToT.

anna retitled this revision from [LICM] Add a diagnostic analysis for identifying alias information of loads within loop to [LICM] Add a diagnostic analysis for identifying alias information.Aug 17 2018, 6:44 AM
anna edited the summary of this revision. (Show Details)
This revision was automatically updated to reflect the committed changes.