search for: d46336

( ​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 "-ins...

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, > ​open questions for me would be > ​​: > > > 1. Since -reas...

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 Here's a basic motivating example that we fail to optimize: https://godbolt.org/g/64N...

...ke having *separate* folds within instcombine, each tested on it's own, (much like clang-tidy checks vs monolithic clang diagnostics) and then somehow combined, not unlike the usual optimization pipelines. The second problem is the size/complexity of the instcombine pass. I do acknowledge that D46336 / D46595 (both in instcombine) is an improvement, which results in more folds that didn't happen before. But it makes the already-large inscombine even more complex, and i'm not sure how it affects the performance. Then there is D45842. That code is pretty simple, and takes ~one page. It d...

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 discussion.) >> >> If >> ​we will >> move >> ​reassociation, >> or keep additional ones >> ​,​ >> out of instcombine, >> ​open questions for me wou...

...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 discussion.) >>> >>> If >>> ​we will >>> move >>> ​reassociation, >>> or keep additional ones >>> ​,​ >>> out of instcomb...

...gt;>>> >>>> >>>> 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 ke...

...g> >> 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 discussion.) >>>> >>>> If >>>> ​we will >>>> move >>>> ​reassociation, >>>> or keep additional ones >>>&...

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

...;>> 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 >>>&gt...

...Yamauchi via llvm-dev <llvm-dev at lists.llvm.org > <mailto: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 >...

...y 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 >>>>>>>&g...

> 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

...M, 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 >>&g...