User Details
- User Since
- Sep 1 2015, 3:36 AM (394 w, 4 d)
Sep 8 2021
Sep 2 2021
Jun 9 2021
Jun 1 2021
May 29 2021
May 23 2021
LGTM
May 16 2021
May 15 2021
@AsafFisher I don't have time for this ATM. Feel free to take over.
Probably you can simplify this patch, so it doesn't touch segments
May 13 2021
May 10 2021
May 5 2021
LGTM
May 4 2021
Could you explain why -debug-pass-manager doesn't fit your use case?
May 3 2021
I've already run into having to update these two golden file tests twice
Apr 30 2021
Should be fixed with c81ec19fba27ec
Apr 29 2021
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
Apr 28 2021
Addressed comments
Added clang test
Apr 23 2021
Addressed comments
Apr 15 2021
Rebased and addressed comments from @lattner (I've removed the dead-store-status.ll because it is specific to CleanupPointerRootUsers)
Apr 14 2021
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)
Apr 13 2021
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
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!
Thanks, LGTM
@dmgreen Nice find again, thanks. Somehow I missed that. I've fixed the issue and checked ARM and AArch64 targets - looks good so far.
Addressed
- 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
Simplified
Nov 2 2020
Oct 30 2020
@dmgreen Nice find! I've fixed it
Oct 29 2020
Addressed
Ping