This is an archive of the discontinued LLVM Phabricator instance.

[Polly] Fix assertion due to buildMemoryAccess.
ClosedPublic

Authored by huihuiz on Jun 21 2016, 7:07 PM.

Details

Summary

For llvm the memory accesses from nonaffine loops should be visible, however for polly those nonaffine loops should be invisible/boxed.

Diff Detail

Repository
rL LLVM

Event Timeline

huihuiz updated this revision to Diff 61488.Jun 21 2016, 7:07 PM
huihuiz retitled this revision from to [Polly] Fix assertion due to buildMemoryAccess..
huihuiz updated this object.
huihuiz set the repository for this revision to rL LLVM.
Meinersbur edited edge metadata.Jun 22 2016, 6:51 AM

Thank you for the patch.

Given the following example:

for (int i = 0; i < 10; i+=1) { /* affine loop */
  if (isConditionTrue()) { /* non-affine subregion */
      int j;
      for (j = 0; j < 20; j +=1) { /* boxed loop */
        A[j] = ...;
      }
      B[j] = ...;
  }
}

The access B[j] can be simplified to B[20], which is correct and done by getSCEVAtScope(). It is also an affine access.

The access A[j] cannot be simplified this way and we probably should not consider it affine.

As far as I looked into it, you patch works because SCEVValidator sees a SCEVAddRecExpr that is not in the current scope. This was not its original intention as seen by the message it prints with -debug:

DEBUG(dbgs() << "INVALID: AddRec out of a loop whose exit value is not "
                "synthesizable");

That happened when getSCEVAtScope() returned something that still contained the SCEVAddRecExpr even though it was not in the loop because ScalarEvolution cannot determine how many round-trips the loop does. In the example above, getSCEVAtScope would happily simplify the expression to A[20], i.e. getSCEVAtScope is not just an expression simplifier anymore.

Can you do the following changes to the patch?

  • Change the DEBUG(dbgs() ..) message accordingly (maybe "Loop of AddRec expression boxed in an a non-affine subregion or has a non-synthesizable exit value.")
  • Put a comment somewhere saying to not call getSCEVAtScope() on the result of getFirstNonBoxedLoopFor()
  • Add a comment into the code explaining why we need getFirstNonBoxedLoopFor.
  • Add a test case like the example above checking that the access A[j] accesses the range A[0..19] and, not the element A[20].
  • Add pollydev and llvm-commits as subscribers

Thanks in advance.

huihuiz updated this revision to Diff 61632.Jun 22 2016, 7:20 PM
huihuiz edited edge metadata.
huihuiz added subscribers: pollydev, llvm-commits.

Update based on reviewer's feedback.

Meinersbur accepted this revision.Jun 27 2016, 3:27 PM
Meinersbur edited edge metadata.
Meinersbur added inline comments.
lib/Analysis/ScopInfo.cpp
4372–4375 ↗(On Diff #61632)

It would be better if this was the added to the documentation of getFirstNonBoxedLoopFor() instead of copying it three times.

polly -> Polly as it is a name

The backticks are Markdown syntax. They work in Phabricator but not in plain text/Doxygen.

as we need to analyze _the_ memory access_es_ of the nonaffine/boxed loops.

Please also describe the effect of getSCEVAtScope on it (it tries to remove the SCEVAddRecExpr to get an explicit expression for a use /outside/ the loop; the use is still inside and would not be detectable by SCEVValidator anymore)

test/DependenceInfo/nonaffine-condition-buildMemoryAccess.ll
1–74 ↗(On Diff #61632)

Thanks a lot for the test case!

This revision is now accepted and ready to land.Jun 27 2016, 3:27 PM
huihuiz updated this revision to Diff 62503.Jul 1 2016, 9:33 AM
huihuiz edited edge metadata.

Update based on reviewer's feedback.

When applying to the current trunk, polly-check fails with

opt: Unknown command line argument '-debug-only=polly-dependence'. Try: 'opt -help'

Can you rebase to the current trunk? Also, add the information that were there in the version before the last update, specifically the information why getFirstNonBoxedLoopFor is needed an that getSCEVForScope should not be called on its output.

grosser edited edge metadata.Jul 5 2016, 7:51 AM
grosser added a subscriber: grosser.

[Drop the comment marker to make sure this gets added to phabricator]

Meinersbur added a comment.

When applying to the current trunk, polly-check fails with

opt: Unknown command line argument '-debug-only=polly-dependence'. Try:
'opt -help'

If this is an no-asserts build then the test case probably misses a

REQUIRES: ASSERTS

Best,
Tobias

huihuiz added a subscriber: huihuiz.Jul 5 2016, 4:30 PM

Hey Michael,

The current trunk I am using is up-to-date, git commit id
b1db6fae50da2c222f98aea982a9685352cd88ff
Author: Tobias Grosser <tobias@grosser.es>
Date: Tue Jul 5 15:26:33 2016 +0000

cmake: do not check-format anything in lib/External

The command line pass just fine "opt -polly -polly-process-unprofitable
-polly-codegen -polly-allow-nonaffine-loops -polly-allow-nonaffine
-debug-only=polly-dependence
test/DependenceInfo/nonaffine-condition-buildMemoryAccess.ll "

I didn't see any failure with this test case. I will join the polly
discuss tomorrow morning to see what's the problem?

I can add the comment back, once we figure out the problem with this
test case.

Thanks!
-Huihui

huihuiz updated this revision to Diff 62813.Jul 5 2016, 7:21 PM
huihuiz edited edge metadata.

Add REQUIRES: asserts in case of no-asserts build

Thanks Tobias for hinting to the REQUIRES: asserts and thanks Huihui for already adding them. This indeed works.

Please do not duplicate the same comment three times, but add it to a single place. In this case, as a comment to getFirstNonBoxedLoopFor().

huihuiz updated this revision to Diff 62897.Jul 6 2016, 9:55 AM

Update comments

This revision was automatically updated to reflect the committed changes.