Wed, May 5
Tue, May 4
Could you explain why -debug-pass-manager doesn't fit your use case?
Mon, May 3
I've already run into having to update these two golden file tests twice
Fri, Apr 30
Should be fixed with c81ec19fba27ec
Thu, Apr 29
Hm ... I see BarrierNoop pass being added before annotation-remarks. Why's that?
@haowei What are LLVM configuration options? Also please send output from
/opt/s/w/ir/x/w/staging/llvm_build/bin/clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm /opt/s/w/ir/x/w/llvm-project/clang/test/Driver/debug-pass-structure.c -o /dev/null 2>&1
Wed, Apr 28
Added clang test
Fri, Apr 23
Thu, Apr 15
Rebased and addressed comments from @lattner (I've removed the dead-store-status.ll because it is specific to CleanupPointerRootUsers)
Wed, Apr 14
As far as I can tell, the breakage of -fsanitize=leak was not known prior to the commit
What kind of breakage? According to @MaskRay (I've just verified his code) LSAN detects memory leak when valgrind hack is reversed, so there is at least some improvement, not breakage. Even if LSAN needs to keep pointer globals for some reason then it can do so from instrumentation pass, because LSAN is part of LLVM. I see no reason why hacks should reside in LLVM trunk to appease some third party tools.
Just how much do we gain by eliminating these locations? Are we talking 10%, 1%, or what?
I don't know, but preventing optimization to appease valgrind looks .. hm.. strange. I agree with @nlopes that __attribute__((__used__)) should be used for such purpose (probably added from some instrumentation pass)
Tue, Apr 13
Apr 1 2021
Fix windows buildbot failure
Mar 30 2021
Not sure you are still interested in this patch. If so, I would suggest you get in touch with some Google folks and check with them if their codebase is ready for this patch. They were the only reason for this workaround.
Dec 30 2020
Regarding the PMUL latency the optimization guide says this. AArch64SchedA57.td probably has older latencies. Should these be updated?
Dec 21 2020
Dec 7 2020
Dec 4 2020
Recommitted in rG993eaf2d69d8
^ Oh that's a shame. Any idea what was causing the output to be different? This fixed a problem we were seeing (and are now seeing again) in one of our downstream schedules.
Nov 30 2020
Also simplify CodeGenSchedTransition
Nov 27 2020
Patch also lowers time of AArch64 subtarget generation from ~13s to ~10s in Debug build and from ~6s to 2.5s in Release build on my PC
@dmgreen After some studying I came up with different approach: if we get rid of artifical 'AnyCPU' (zero) processor index and explicitly create one PredTransition per processor, we can use much simpler algorithm for variant expansion. Besides fixing read variant compilation issues this also fixes few other things:
Nov 25 2020
Nov 24 2020
@andreadb Built all targets, looks like none is touched (checked RISCV, AMDGPU, PPC, Lanai, etc)
When you say that " Subtarget files are unchanged by the patch", does it mean that you have checked all the targets or just ARM?
Needs to be rebased
Addressed. Revision now depends on D92029
Nov 23 2020
Addressed. Thanks for insights!
@dmgreen Nice find again, thanks. Somehow I missed that. I've fixed the issue and checked ARM and AArch64 targets - looks good so far.
- Added check for Thumb1, because Thumb2 instructions follow different encoding rules
- Added comments
Nov 18 2020
Nov 11 2020
Fixed issue with accessing wrong element in vector
Nov 9 2020
Nov 7 2020
I'm not sure if I see how both halves are related here. Is this a problem that you found, so you altered the A57 to show that issue, so the tablegen code fixes the issue?
Nov 6 2020
Eliminated unused variable
Nov 5 2020
Nov 2 2020
Oct 30 2020
@dmgreen Nice find! I've fixed it
Oct 29 2020
Oct 26 2020
Oct 23 2020
Are we sure that the lowering of MachineInstr to MCInst is preserving the operand sequence? Can it be that the immediate is at position 4 for the MCInst only?
I have no idea how an ldrbt looks like as a MachineInstr. The original check should have triggered an assertion too for MachineInstr then...