similar to: [LLVMdev] r156323 - Reassociate FP operands.

> Hi Chad, > > Thanks for you answer. > >> On Feb 4, 2015, at 11:22 AM, Chad Rosier <mcrosier at codeaurora.org> >> wrote: >> >>>> On Feb 2, 2015, at 11:12 AM, Mehdi Amini <mehdi.amini at apple.com> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I encountered some bugs in Reassociate [1] where we

>> On Feb 2, 2015, at 11:12 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Hi, >> >> I encountered some bugs in Reassociate [1] where we are hitting some >> assertions: >> >> assert(!Duplicates.count(Factor) && >> "Shouldn't have two constant factors, missed a >> canonicalize");

Hi, > I tried it with -o - but its producing an error > > gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files > > What you suggest? what I wrote: >> for F in *.c ; do B=`basename $F .c` ; gcc -fplugin=/path/to/dragonegg.so >> -S -o - $F -fplugin-arg-dragonegg-emit-ir | opt -adce -o $B.ll ; done >> clang *.ll Thanks to the for loop and

Hi, > If I compile the program using the following command line i.e. > > $ clang -O3 -lm *.c this may be doing link time optimization. > > then > > $ time ./a.out > > real 0m2.606s > user 0m2.584s > sys 0m0.012s > > BUT, if I use all the optimizations enabled with -O3 but specify them > explicity i.e. you can just use "opt -O3"

Hello I need some help here please. If we compile source files directly in to native code: $ clang -O3 -lm *.c then the runtime is like following real 0m2.807s user 0m2.784s sys 0m0.012s and If we emit LLVM bytcode and apply optimizations $ clang -O3 -c -emit-llvm *.c $ llvm-link *.o -o comb.ll $ time lli ./comb.ll then the runtime is real 0m2.671s user 0m2.640s sys 0m0.020s But, if I

Hi Yes, they both are exactly the same. Regards Shahzad On Tue, Jun 12, 2012 at 9:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, is the comb.ll used here: > > >> $ time lli ./comb.ll >> >> then the runtime is >> >> real    0m2.671s >> user    0m2.640s >> sys     0m0.020s >> >> But, if I convert this same file comb,ll

Hello Duncan Sorry for the mistake. Actually that error occurred when I was compiling all the files at once, NOT in for loop. The for loop is working perfectly as it is dealing with individual files. I have now one new issue. Let me specify it briefly. If I compile the program using the following command line i.e. $ clang -O3 -lm *.c then $ time ./a.out real 0m2.606s user 0m2.584s sys

Thanks Duncan It was really helpful. Regards Abdul On Fri, Jun 8, 2012 at 7:23 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> If I compile the program using the following command line i.e. >> >> $ clang -O3 -lm *.c > > > this may be doing link time optimization. > > >> >> then >> >> $ time ./a.out >>

Hi, is the comb.ll used here: > $ time lli ./comb.ll > > then the runtime is > > real 0m2.671s > user 0m2.640s > sys 0m0.020s > > But, if I convert this same file comb,ll in to native binary the same as the comb.ll used here: > $ clang comb.ll ? Ciao, Duncan. > > and execute it, then the runtime increases alot > > $ time ./a.out > > real

Hi, > Yes, they both are exactly the same. then I don't know what is going on. I suggest you send a copy of comb.ll to the list so that we can see for ourselves. Ciao, Duncan. > > Regards > > Shahzad > > On Tue, Jun 12, 2012 at 9:38 AM, Duncan Sands<baldrick at free.fr> wrote: >> Hi, is the comb.ll used here: >> >> >>> $ time lli

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

Thanks alot Chad for quick response. Does this means that, we can not use LLVM optimizations except O1, O2, O3, O4 and unroll-loops with clang? One more thing I would like to know that If I want to process multiple modules with opt at the same time like opt -adce *.bc then how is it possible with opt in one go, if I process all the bytecode files within Makefile. Thanks. Shahzad On Thu, Jun

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

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

Hi Shahzad, > Is it possible that we can use LLVM optimization beside O1, O2, O3 > along with dragonegg plugin? sure, try this: gcc -fplugin=path/dragonegg.so ...other_options_here... -S -o - -fplugin-arg-dragonegg-emit-ir -fplugin-arg-dragonegg-llvm-ir-optimize=0 | opt -pass1 -pass2 ... Here -fplugin-arg-dragonegg-emit-ir tells it to output LLVM IR rather than target assembler.

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

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

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