- User Since
- Oct 14 2014, 7:04 AM (313 w, 6 d)
Mon, Oct 5
Do you mean to improve the existing LLVM Jump Threading pass?
Yes, either improve current one or write new more powerful JT pass.
Fri, Sep 25
This patch is not supposed to be used as is. It can be used for experiments and as a proof of concept. A version for reviewing will be submitted soon.
Sep 16 2020
Feb 15 2019
Jan 16 2019
Jan 15 2019
Nov 23 2018
I'd like someone from the X86 world to approve this as well.
Nov 21 2018
Oct 31 2018
May 14 2018
May 11 2018
We might need to play with _GLIBCXX_USE_CXX11_ABI=0 and the -Wabi-tag option to mitigate libstdc++ ABI issues.
Feb 27 2018
Maybe it's worth to send the API change to llvm-dev as RFC?
Feb 21 2018
Just validated that it has fixed the issue.
Thank you, Peter.
Feb 20 2018
Feb 8 2018
Jan 31 2018
Jan 30 2018
Jan 24 2018
Jan 23 2018
Jan 22 2018
Jan 19 2018
Jan 18 2018
Thank you, Joel. The function to look at is make_list.
In SingleSource/Benchmarks/McGill/chomp the patch causes generation of subs+cmp_with_0 instead of only a subs.
The patch caused regressions in LNT benchmarks on Cortex-A9:
Jan 17 2018
Hi Sergey and Sanjoy,
Jan 16 2018
Jan 15 2018
Jan 12 2018
I have found that the patch also caused 7.31% regression in SPEC2k6 401.bzip2 on Cortex-A57 (AArch64).
Jan 11 2018
Thank you for the initial analysis. I'll try to debug SCEV.
Jan 10 2018
Jan 9 2018
The patch looks OK to me if using std::to_string is allowed now.
Dec 18 2017
Dec 15 2017
Dec 14 2017
Dec 5 2017
$ llc -O3 test_crash.ll llc: /home/llvm-test/tmp/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1002: void (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode *): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || TLI.isTypeLegal(Op.getValueType()) || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed. ...
Dec 4 2017
Dec 1 2017
There are stability and correctness issues on AArch64. The similar issues might exist on other ARM targets. Could you please disable MergeConsecutiveStores for all ARM targets including AArch64?
These changes caused failures of AArch64 NEON Emperor tests.
These changes caused Clang to crash when it compiled spec2006 403.gcc for AArch64. I am working on a reproducer.
Nov 30 2017
Nov 29 2017
Nov 28 2017
Nov 22 2017
@evgeny777: I'll try to find some time to look at 401.bzip2.
Nov 9 2017
Nov 8 2017
I've got Spec2006 results for Cortex-A57:
Nov 3 2017
Cortex-A57 results from another private benchmark (50 sub-benchmarks):
I've got first results of benchmark runs: the LNT test suite + a private benchmark 01. I used the latest patch.
The configuration is a Juno board Cortex-A57/A53, v8-a, AArch32, Thumb2.
Options: -O3 -mcpu=cortex-a57 -mthumb -fomit-frame-pointer
The runs passed without errors.
Oct 31 2017
I'll do AArch32/AArch64 benchmarks runs on our Juno boards. It would be worth to run CTMark to check compilation time.
Oct 27 2017
Oct 26 2017
This patch caused SingleSource/Benchmarks/Shootout/shootout-sieve regression on Arm public bots:
Oct 14 2017
The patch has caused a few regressions on Arm too. They are within 5%. We investigated some of them. For example, the unrolling is not applied. However the unrolling could figure out that some non-free GEPs are removed during optimisation. Maybe other passes have the similar problem. We currently need more precise cost model for inlining at Oz. However we started looking at the recently introduced TTI code size cost if we can use it.
At which optimisation level is the inlining affected? Could we fix the issues by updating the heuristics?
Oct 5 2017
Thank you, Justin.
Oct 4 2017
Oct 3 2017
Thank you, Jun, for fixing this.
There is PR33642 with a test case when TCC_FREE is returned for non-cost free GEPs.
Thank you, Eli.
Oct 2 2017
Sep 26 2017
Sep 25 2017
Sep 1 2017
Thank you, Renato, for clarifying that.
BTW the issue was found during porting micropython for Cortex-M0 from GCC to Clang.
Aug 25 2017
As this patch can affect ARM targets I am doing some benchmarking.
I've got the LNT benchmarks results for AArch64 (Cortex-A57). There is no difference in performance. I'll have got more results soon.
It's interesting to see what benchmarks has been used to measure the improvements.
Thank you, Haicheng.
Aug 24 2017
Thank you, Eli.