User Details
- User Since
- Nov 28 2018, 11:44 AM (225 w, 1 d)
Wed, Mar 1
Patch was reverted due to issue witch cached MemDep result. There is a code like this:
%arrayidx248 = getelementptr inbounds [0 x i8], ptr @zz_lengths, i64 0, i64 %idxprom247 %cond.in.in = select i1 %switch8091, ptr %orec_size, ptr %arrayidx248 %cond.in = load i8, ptr %cond.in.in, align 1, !tbaa !5
And on second iteration of processBlock() %switch8091 value is proved to be false, so select is removed and replaced with %arrayidx248, but we didn't invalidate already cached SelectDep entry of load from first GVN iteration - need to figure out how to add this logic into MemoryDependenceResults::removeInstruction method.
Mon, Feb 27
Feb 20 2023
Thank you for the review! I will wait some time in case of other reviewers' objections and then merge it.
Feb 10 2023
Insert select before predecessor's terminator to simplify clobbers search
Feb 7 2023
I want to put more context for this change that may cover some questions regarding the algorithm and its limitations. Let's consider the following simple case:
BB1 / | BB2 | \ | BB3
Feb 6 2023
Address review comments
Feb 3 2023
Update patch
Separate patch for removing isSafeToSpeculativelyExecute() checks: https://reviews.llvm.org/D143255
Added synthetic test for simplifyCastInst
Feb 2 2023
Split patches
Split patch
Remove isSafeToSpeculativelyExecute() checks
Separate patch with code changes: https://reviews.llvm.org/D143171
Split renaming and code changes
Since naming conventions are indeed broken across many PHITransAddr methods, maybe it's worth to clean up them first.
Feb 1 2023
Jan 27 2023
Jan 20 2023
Thank you for the reviews!
Jan 18 2023
I have a question regarding code example: it looks like a case of load hoisting from SuccBB and basic block after splitting of (PredBB, LoadBB) critical edge. If so, the same result can be achieved by:
- running SimplifyCFGOpt::HoistThenElseCodeToIf after GVN. Its implementation is very constrained (can hoist only first N exactly the same instructions from ThenBB and ElseBB, so very sensitive to instruction order)
- Run GVNHoist pass after GVN -- the most general solution. Unfortunately it's disabled by default and placed before GVN in pass pipeline (although GVN exposes lots of hoisting opportunities, and its authors advise to run it before and after GVN-PRE).
Jan 17 2023
Check that load types are matched (add negative test for that)
Jan 16 2023
Rebase
Split pre-commit test
Treat select as Def dependency
Since extending MemDepResult looks not feasable (and replacing it to tag-pointer pair also looks bad because it frequently passed by value), I think we can treat select dependency as Def. It also fits naturally into existing GVN infra, and the meaning of Def dependency is already overloaded (it can be other load/store/alloca/memory intrinsic/etc.)
Jan 13 2023
Split findDominatingLoad() rework into separate patch
Split AnalyzeLoadAvailability refactoring into separate patch: https://reviews.llvm.org/D141664
Jan 12 2023
Dec 28 2022
Ping (this pass is mostly profitable for RISC-V target, because zext on this target has non-zero cost, and the intention is to report Coremark results for RISC-V with this optimization enabled, like with DFA jump threading)
Dec 23 2022
Dec 8 2022
Compile-time results on llvm-test-suite + SPEC2006 + SPEC2017:
Program loop-int-wrap-predication.NumPredicatedChains
Rebased on ToT
Add predication on separate conditions
Add simple cost model (do not predicate big loops)
Dec 6 2022
Dec 5 2022
Fix diff
Addressing review comments
Insert freeze of select condition