similar to: Register Spill Caused by the Reassociation pass

This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact. Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like

Thank you, Adam. It passes all the benchmarks I have. Haicheng From: anemet at apple.com [mailto:anemet at apple.com] Sent: Wednesday, March 09, 2016 7:17 PM To: Haicheng Wu; Eric Christopher; Benjamin Kramer Cc: llvm-dev Subject: Re: Regression in SPEC2006/gcc caused by LoopLoadElimination I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys please give it a

> On Mar 7, 2016, at 9:43 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Haicheng, > > Sorry about the breakage. I reverted it in r262839. > > I will try to reproduce it locally. Please don’t blow away your directories yet in case I need further help. OK, I managed to reproduce this locally. Should be able to make progress from here without further help from

Hi Adam, I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either "-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing". Please let me know if you need more information. Best, Haicheng -------------- next part -------------- An HTML attachment was

On Thu, Mar 10, 2016 at 1:17 AM, Adam Nemet <anemet at apple.com> wrote: > I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys > please give it a test with your codebase. (You need to enable the pass with > -mllvm -enable-loop-load-elim.) The miscompilation I was seeing is gone now, too. Thanks! > On Mar 7, 2016, at 11:05 PM, Adam Nemet <anemet at

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-folder -block-placement) targeting

Hi, I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 out 17 of floating point benchmarks passed. Is this normal or I made a mistake in my build? Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/4c4a81a9/attachment.html>

On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > Hi, > > I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 > out 17 of floating point benchmarks passed. Is this normal or I > made a mistake in my build? Hi Reza. Somebody on Linux should answer, but I don't think it's normal. You may have checked out the source at a moment when it had a bug

( ​I came across this issue in the context of D46336 <https://reviews.llvm.org/D46336>. ​ ​ Thanks, Sanjay, for starting this discussion.) If ​we will move ​reassociation, or keep additional ones ​,​ out of instcombine, ​open questions for me would be ​​: 1. Since -reassociate isn't a fixed point pass, we might need to repeat "-instcombine -reassociate" multiple times to

1. The reassociate pass that exists right now was *originally* (AFAIK) written to enable CSE/GVN to do better. That particular issue is solvable in other ways, because there are good ways to integrate reassociation into CSE/GVN (and at this point, it would probably be cheaper than -reassociate since it would modify code less, only changing it when there are actual redundancies ) I don't know

There are at least 3 active proposals to add reassociative optimizations in IR: [1] D41574 <https://reviews.llvm.org/D41574>- a new pass for reassociation/factoring [2] D46336 <https://reviews.llvm.org/D46336> - enhance -instcombine to do more reassociation/factoring [3] D45842 <https://reviews.llvm.org/D45842> - add to the existing -reassociate pass to enable factoring

When you say that distribution shouldn't be used, do you mean within instcombine rather than some other pass? Or not all as an IR optimization? A dedicated optimization pass that looks for and makes factoring/distribution folds to eliminate instructions seems like it would solve the problems that I'm seeing. Ie, I'm leaning towards the proposal here: https://reviews.llvm.org/D41574

On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ( > ​I came across this issue in the context of > D46336 <https://reviews.llvm.org/D46336>. > ​ ​ > Thanks, Sanjay, for starting this discussion.) > > If > ​we will > move > ​reassociation, > or keep additional ones > ​,​ > out of instcombine,

On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> ( >> ​I came across this issue in the context of >> D46336 <https://reviews.llvm.org/D46336>. >> ​ ​ >> Thanks, Sanjay, for starting this

Following is the list of fp benchmarks that fail. They all pass with -O3, but some fail with -O4. I did the test run. Thanks, Reza Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -------------- ------ --------- ---------

On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 10:38 AM,

> On May 8, 2018, at 9:50 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 1. The reassociate pass that exists right now was *originally* (AFAIK) written to enable CSE/GVN to do better. Agreed. The original mindset included a (naive) belief that going with a canonical form was better than teaching redundancy elimination to handle abstractions (as a matter

On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> ( >>> ​I came across this issue in

Hi Devs, I am looking at the bug https://bugs.llvm.org/show_bug.cgi?id=43953 and found that following piece of ir %arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom %0 = load float, float* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom %1 = load float, float* %arrayidx2, align 4, !tbaa !2 %sub = fsub fast float %0, %1

On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 10:39 AM, Hiroshi