[PATCH] D141712: [GVN] Improve PRE on load instructions
Guozhi Wei via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 26 12:32:37 PST 2023
Carrot added a comment.
In D141712#4082217 <https://reviews.llvm.org/D141712#4082217>, @nikic wrote:
> It looks like the new version of the patch ended up being more expensive in terms of compile-time: Original <http://llvm-compile-time-tracker.com/compare.php?from=fe2ca62e92c82efcbbd10916e352bdfeddb80e19&to=1d81778eee4d4c38db40ec50a5e18ac76e251b44&stat=instructions:u>, New <http://llvm-compile-time-tracker.com/compare.php?from=287508cd9c4396c8845d92310d258879202a179e&to=5f1448fe1585b5677d5f0064e4eeac3b493d8a18&stat=instructions%3Au>
>
> I wonder whether this is because not removing the load essentially always forces an extra GVN iteration?
I think so, it causes all triggering cases need another iteration.
================
Comment at: llvm/lib/Transforms/Scalar/GVN.cpp:1462
+ if (uint32_t ValNo = VN.lookup(OldLoad, false))
+ removeFromLeaderTable(ValNo, OldLoad, OldLoad->getParent());
+ // To avoid deleting an instruction from different BB, we just leave
----------------
nikic wrote:
> If we're not removing the load, we probably shouldn't be removing it from the leader table either?
Because we expect it to be deleted in the next iteration, and the same value is also available in the NewLoad instruction, so I think it should not be used by other optimizations, and assume it's not available in the leader table.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141712/new/
https://reviews.llvm.org/D141712
More information about the llvm-commits
mailing list