If all available vals to basic block are the same - do not build new phi node and
just use this value.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This is interesting! Can you please make a simple/dedicated LLVM IR case for this only, so we can go over the example to get the whole picture?
llvm/test/CodeGen/AArch64/tail-dup-redundant-phi.mir is dedicated test for this patch and https://reviews.llvm.org/D126523. This test is not landed yet. I just uploaded it here as diff to show the difference.
Requesting @arsenm to take a look at the AMDGPU test.
llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h | ||
---|---|---|
332 | Is this assert really needed? For someone unfamiliar with this code (like me), seeing this assert creates a doubt about the surrounding code ... as if there are complicated paths reaching here, where it might be possible that the BBInfo may be in an invalid state at this point. | |
338 | Is this assert really needed? | |
347 | When is "Info->AvailableVal" assigned? If it's the same as the previous statement, then the implicit identity relationship between BBMap[Info->BB] and Info is quite confusing. Can this function be rewritten to consistently use just one of these two expressions? |
llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h | ||
---|---|---|
332 | This is more or less paranoid. The comment for BBInfo class states that predecessor info is a cache to speedup predecessor traversal. | |
338 |
ditto | |
347 |
Incoming Info object comes from BlockList which is filled in BuildBlockList where BBMap is filled. So in reality BBMap[Info->BB] == Info and this is something complicated traversal, so I've added the assert above. I wrote the code in this way to ensure that all "outer" data structures are filled. |
That would be good but SSA Updater is not triggered directly as a pass. I found the motivation case in tailduplication codegen pass, so I've written it in mir format. Writing it in LLVM IR will just include a lot of other passes where the changes might disappear the case I'm testing. I though the more precise test is better than something general.
If you'd like I can try to create unittest triggering directly SSA Updater.
llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h | ||
---|---|---|
332 | Yeah, I think we should not have this assert. Cache or not, it is quite reasonable to bravely work under the assumption that the array contains valid elements if NumPreds is non-zero. If the cache were unreliable, then there should be a function such as "fetchPreds" or something, to be called by any point in code where the preds must be valid. | |
347 | I don't think there is any side-effect in the BBMap container other than this one pointer being updated. I think it's more readable to update only Info. If it is useful to be paranoid, then the assert should be on "BBMap[Info->BB] == Info". |
I see now. I looked into the places where SSAUpdater is used, and I am okay with not having an LLVM IR or unit test here.
The code looks okay to me, but still need @arsenm to check the effect on the AMDGPU lit test. There seem to be superficial changes to the control flow, but Matt might be able to say whether the test still serves its original purpose after this change.
Thanks! I'll wait for 1-2 days for @arsenm feedback before landing the patch.
If you do not mind, may I ask you to look at https://reviews.llvm.org/D126523. It is pretty close but after this patch, that patch might be considered as compile time improvement.
ok, I take a liberty to land this and ready to revert or follow-up basing on @arsenm feedback.
Nit: s/val/value/