Fix problems in handling of summation reduction and invariant expressions in Expressions Simplification #6747
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In considering whether to pull an invariant expression out of a loop, removeUncertainBlocks needs to verify that blocks that are being considered will be executed exactly once within the region that contains them. If a block is nested within another loop in the region, it might be executed more or less than one time, and so should be removed from consideration. Also removed some stray tab characters.
|
Devin @jdmpapin and Vijay @vijaysun-omr, may I ask you to review this change? |
vijaysun-omr
reviewed
Oct 5, 2022
vijaysun-omr
approved these changes
Oct 5, 2022
vijaysun-omr
approved these changes
Oct 5, 2022
|
Jenkins build all |
|
I will wait for @jdmpapin review before considering this for merging. |
jdmpapin
reviewed
Oct 6, 2022
Expressions Simplification looks for summation reductions and invariant expressions that can be pulled out of loops. Each instance is tracked by placing the TR::TreeTop of the candidate in a TR::List. However, in the process of actually performing the transformation, <some method> doesn't perform the same checking of a summation reduction as it does during the initial analysis. In particular, an invariant expression that happens to involve an ineg, ixor, isub or iadd might end up being transformed as if it was a summation reduction. Fixed this by using a list of candidates that carries a flag indicating the kind of transformation that can be performed along with the TR::TreeTop.
hzongaro
force-pushed
the
issue-15534-expr-simplification-loop-invariant
branch
from
7f4dd02
to
5975854
Compare
|
Squashed trace message change in commit 5975854. No other changes. |
jdmpapin
approved these changes
Oct 11, 2022
|
All checks passed for the revision that Vijay approved. The only difference between that revision and the current one is from 7f4dd02 (now squashed), which only affects tracing, so I think that once the current builds pass, this is fine to merge without another "build all." |
|
Thanks, as mentioned the only change is in the area of tracing and since basic/build checks have now passed, I am merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request fixes two problem in Expressions Simplification.
TR_ExpressionsSimplification::removeUncertainBlockschecks whether blocks will be executed exactly once within each iteration of the loop, and if not, it removes them from consideration. It does this by checking whether the block post-dominates the entry block for the loop. However, if a block is in another loop nested within the loop, it might post-dominate the entry but still be executed more than once in each iteration of the outer loop. Such blocks must also be removed from consideration.TR::TreeToppointers. It later iterates over the candidates, and in checking whether it's working with a summation reduction candidate, it simply checks whether the first child operation of the store is one ofiadd,isub,ixororineg. However, a candidate for an invariant expression transformation might also have one of those operations as the first child of its store operation. This can result in an invariant expression candidate being transformed as if it had been summation reduction candidate.Fixed this by changing the list of candidate
TR::TreeToppointers into a list ofSimplificationCandidateTupleobjects that contain the candidateTR::TreeTopalong with flags indicating the kind of candidate it is.Fixes eclipse-openj9/openj9#15306