For llvm the memory accesses from nonaffine loops should be visible, however for polly those nonaffine loops should be invisible/boxed.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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.
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.
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! |
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.
[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
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
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().