Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@Dimoner please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
|
The idea is good (I'm sure there are open issues/ideas for it already here), but presumably it should be better than just relying on lvIsParam which is way too conservative. It should detect all truly loop invariant operands, I'm not sure what would be the best phase for that. Maybe as part of loop clonning. |
|
Loop cloning? Maybe. It has a simple model for loop invariance. Once we have SSA we have a better model, and one that's easier to reason about. |
But unfortunately Loop Hoisting happens before that 😞 (if that is the main goal, presumably, even without the hoisting it's still beneficial to do) |
This PR improves loop invariant code motion opportunities for integer arithmetic by making loop-invariant subexpressions easier to recognize and hoist.
For loops like:
the JIT currently keeps the expression as a chain of ADDs where loop-variant and loop-invariant terms are interleaved. As a result, the invariant part (x + y + x1) is not formed as a standalone subtree, so PHASE Hoist loop code cannot hoist it.
Generated code therefore performs redundant additions of x, y, and x1 inside the loop body, even though they are invariant.
Asm
During morphing, we reassociate commutative/associative integer arithmetic trees (starting with GT_ADD) into a more canonical form that groups loop-invariant operands together.
Asm
This optimization could potentially be extended beyond integer arithmetic.
In particular, a similar reassociation approach may be applicable to certain
string concatenation patterns, where loop-invariant fragments could be
identified and computed outside the loop.
The current implementation intentionally targets a narrow scenario and
handles only a single reassociation case for integer addition. If this
direction is considered valid, the transformation can be generalized to
cover additional arithmetic patterns and operators in follow-up changes.
Bench for string
Result