[CodeGen][ShrinkWrap] Clarify StackAddressUsedBlockInfo meaning #80679
Conversation
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write If you have received no comments on your PR for a week, you can request a review If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
@MatzeB, please, take a look. |
|
@qcolombet, may be you have any comments? |
llvm/lib/CodeGen/ShrinkWrap.cpp
Outdated
| /// the block itself. | ||
| /// Is `true` for the block numbers where we cannot guarantee that there will | ||
| /// be no access to the stack or computation of stack-relative addresses on | ||
| /// any CFG path including the block itself. |
There was a problem hiding this comment.
The comment is indeed out of date.
Is true => there may be a stack access or computation of ... (i.e., just drop the no from the original comment)
Is false => no stack access or computation
There was a problem hiding this comment.
I agree that after my changes comment looks too complicated.
Nevertheless if I simply drop no from the original comment, we'll get
/// Is `true` for block numbers where we can guarantee stack access
/// or computation of stack-relative addresses on any CFG path including
/// the block itself.
which means, what we are sure that there will be access to the stack or computation of stack-relative addresses. But really we only assume it.
May be it will be better to write
/// Is `true` for block numbers where we assume possible stack access
/// or computation of stack-relative addresses on any CFG path including
/// the block itself.
There was a problem hiding this comment.
Yes, that’s why I said “may”.
And call out the false case. Essentially we can have false positive, I.e., we are conservative to remain correct.
Feel free to rephrase!
| @@ -948,6 +948,9 @@ bool ShrinkWrap::runOnMachineFunction(MachineFunction &MF) { | |||
|
|
|||
| bool Changed = false; | |||
|
|
|||
| // Initially, conservatively assume that stack addresses can be used in each | |||
| // basic block and change the state only for those basic blocks for which we | |||
| // were able to prove the opposite. | |||
enoskova-sc
force-pushed
the
users/enoskova-sc/update-shrink-wrap-description
branch
from
47fddd4
to
dd2b04d
Compare
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
enoskova-sc
force-pushed
the
users/enoskova-sc/update-shrink-wrap-description
branch
from
dd2b04d
to
a0b8ba8
Compare
|
@qcolombet, is it now good? |
|
@qcolombet, do you have any more comments? |
|
@fhahn, may be you can comment on this? |
|
@sushgokh, may be you can comment on this? |
|
@enoskova-sc Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested Please check whether problems have been caused by your change specifically, as How to do this, and the rest of the post-merge process, is covered in detail here. If your change does cause a problem, it may be reverted, or you can revert it yourself. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! |
No description provided.