similar to: [LLVMdev] question about llvm.powi and reassociation

> 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

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

Hi, I'm stumped by how to handle fpowi. Here is the context: my architecture has i64, f32, and f64 registers. No i32. For calls & returns, we promote i32 to i64. There is no support in the architecture to perform fpowi - it has to go through the runtime. I'm using gfortran + dragonegg + llvm3.4 to generate .ll files via plugin. The fortran expression REAL = REAL ** INTEGER*4

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

Hello, The purpose of the llvm.powi intrinsic isn't clear to me. Why is llvm.powi preferable to multiplication and division for small constant powers (e.g., 1/x, x*x, etc.)? Why is it preferable to llvm.pow for large variable powers? I'm also curious about the time bound. I'm assuming that powi(x,1000000) doesn't do a million multiplications... Do any architectures have

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

> The purpose of the llvm.powi intrinsic isn't clear to me. Why is > llvm.powi preferable to multiplication and division for small constant > powers (e.g., 1/x, x*x, etc.)? Why is it preferable to llvm.pow for > large variable powers? I'm also curious about the time bound. I'm > assuming that powi(x,1000000) doesn't do a million multiplications... > Do any

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

In the following example with gcc style builtins, in once case llvm.powi.f64 is emitted and in the other just a call to library function powf. ~/llvm/build/Debug+Asserts/bin/clang -S -emit-llvm pow1.c Why is that? Is there a way to force the call to an llvm style builtin? Tia. Reed -------------- next part -------------- A non-text attachment was scrubbed... Name: pow1.c Type: text/x-csrc

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

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

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

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