similar to: [LLVMdev] Dev Meeting BOF: Performance Tracking

On 24 May 2013 17:39, Chad Rosier <mcrosier at apple.com> wrote: > One side effect of dynamically computing the aliases is that the iterator > does not guarantee that the entries are ordered or that duplicates have > been removed. > Hi Chad, Sounds like you're growing the list (thus the lookup time), rather than shrinking, as I take it was Jacob's original intention?

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

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.

Hi Shahzad, > I tried your method and it works fine. What would be the next step to > produce the final executable? I have tried the following but it is > producing an error > > $ gcc -fplugin=/path/to/dragonegg.so -S *.c > -fplugin-arg-dragonegg-emit-ir | opt -adce this won't work because you aren't passing the IR to opt (you need -o - for that if using a pipe) and you

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

Hello Duncan Is it possible that we can use LLVM optimization beside O1, O2, O3 along with dragonegg plugin? Regards Shahzad On Thu, Jun 7, 2012 at 10:59 PM, Abdul Wahid Memon <engrwahidmemon at gmail.com> wrote: > Thanks alot Chad for these quick and fine responses. > > Regards > > Abdul > > On Thu, Jun 7, 2012 at 10:57 PM, Chad Rosier <mcrosier at apple.com>

David/Johan, I would love to claim victory, but I don't think that D34901 catches this case. However, I got interested and threw this together quickly: https://reviews.llvm.org/D35140. This does catch the below case. If people are interested I can add test cases and submit for formal review. FWIW, it does hit about 1/3 of all of the SPEC benchmarks. I haven't done any performance

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 Duncan I tried your method and it works fine. What would be the next step to produce the final executable? I have tried the following but it is producing an error $ gcc -fplugin=/path/to/dragonegg.so -S *.c -fplugin-arg-dragonegg-emit-ir | opt -adce $ clang *.s Regards Shahzad On Fri, Jun 8, 2012 at 9:10 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Shahzad, > >

Hello Duncan On Fri, Jun 8, 2012 at 2:58 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Shahzad, > > >> I tried your method and it works fine. What would be the next step to >> produce the final executable? I have tried the following but it is >> producing an error >> >> $ gcc -fplugin=/path/to/dragonegg.so -S *.c >>

> On Mon, Dec 15, 2014 at 9:57 AM, Chad Rosier <mcrosier at codeaurora.org> > wrote: >> All, >> About two months ago I posted a patch that hoisted the hottest case >> statement from a switch statement during ISelLowering. >> >> See: http://reviews.llvm.org/D5786 >> >> Sean was rather adamant about using a Huffman tree (and I agree this is

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

> On Mon, Dec 15, 2014 at 2:26 PM, Chad Rosier <mcrosier at codeaurora.org> > wrote: >> >> > On Mon, Dec 15, 2014 at 9:57 AM, Chad Rosier <mcrosier at codeaurora.org> >> > wrote: >> >> All, >> >> About two months ago I posted a patch that hoisted the hottest case >> >> statement from a switch statement during

Use the -I<install path>/include . This directory <install path>/include should look something like: clang/ clang-c/ llvm/ llvm-c/ HTH ashok On 7/9/2012 3:15 PM, NY Knicks Fan wrote: > I downloaded the 3.1 LLVM and Clang sources. > > I followed the directions at: http://clang.llvm.org/get_started.html > > I am able to use Clang to compile stuff, but I could

On 7/9/2012 1:42 PM, Chad Rosier wrote: > Have you looked here: http://clang.llvm.org/get_started.html > > Chad > > > On Jul 9, 2012, at 11:33 AM, NY Knicks Fan wrote: > >> I'm trying to do the tutorials at: >> >> https://github.com/loarabia/Clang-tu...i/TutorialOrig >> <https://github.com/loarabia/Clang-tutorial/wiki/TutorialOrig> >>

The "make install" should collect everything into your <install path>. The <install path> will then have bin, lib and include dirs. On 7/9/2012 3:52 PM, NY Knicks Fan wrote: > Hi Ashok, > > The documentation suggests that I put clang inside of llvm/tools and so > I have two separate include directories. I tried both of them and > neither worked: > > $

Sorry, by debug build I actually meant asserts enabled.  Thus, this issue can show up in either a debug or release build, if asserts are enabled. On 10/26/2017 4:05 PM, Chad Rosier via llvm-dev wrote: > > Chandler/All, > > We've just started testing the new pass manager this week and we ran > into a 548x slowdown (i.e., 6.28s to 3443.83s) for one of the files > from

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

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