similar to: more reassociation in IR

( ​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

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

I mentioned this earlier in the thread - I would like to see something like D41574 in the optimizer. It's optimizing code that no other pass does currently, and I don't see any other near-term proposal that gets us those optimizations. Omer, can you rebase that to trunk? I think a header has moved, so it doesn't build as-is. I'd like to know if it can catch the cases in D45842. If

On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> 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 Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM

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 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

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

On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > 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

On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin > <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: > > > > On Thu, May

> 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

My 5 cent, since i've been recently working on instcombine a bit. First of all, I do acknowledge and recognize the problem at hand - the IR is not getting fully optimized. I think that should be solved. As it is evident, LLVM is quite modular, there are separate passes. This is good. It allows to test things separately. Unfortunately, that is also bad, because there are always these things

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

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

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

Hello, all. To get my feet wet and hopefully make a small contribution, I was looking for something small to start with. I settled on one of the suggestions from the CodeGen readme: > Reassociate should turn things like: > > int factorial(int X) { > return X*X*X*X*X*X*X*X; > } > > into llvm.powi calls, allowing the code generator to > produce balanced multiplication

Owen/All, I've been working on adding support for reassociation with unsafe math (see: http://reviews.llvm.org/D4129). Do you know if this change, r156323, is still necessary? Specifically, do we need the reassociation pass to canonicalize FP operands for CSE to work effectively? This kinda scares me if it does! :( Side note: Without this canonicalization, I did see a 3% regression in Mesa

On Tue, May 5, 2015 at 10:31 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote: > > Hi Daniel, > > > > I presume you mean, instead of assigning function arguments distinct > ranks > > (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), > we > > should

Hi Sanjay, I observed some extra register spills when applying the reassociation pass on spec2006 benchmarks and I would like to listen to your advice. For example, function get_new_point_on_quad() of tria_boundary.cc in spec2006/dealII has a sequences of code like this . X=a+b . Y=X+c . Z=Y+d . There are many other instructions between these float adds. The reassociation