similar to: [LLVMdev] using GCC LTO files as a frontend to dragonegg?

On 10 September 2010 14:37, Marcus Daniels <mdaniels at lanl.gov> wrote: >  Hello, > > With GCC, it is possible to compile GIMPLE from an object file back to > assembly.  With Dragonegg, it seems to be a NOP.  (See below for a > comparison.) > > This appears it could be a nice way to mix the strengths of GCC and > LLVM.  If it worked..  Should it? I can't

$ gcc -S test.c $ cat test.s .file "test.c" .text .globl __GI___testfunc .hidden __GI___testfunc .type __GI___testfunc, @function __GI___testfunc: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $0, %eax popq %rbp .cfi_def_cfa 7, 8

On Mon, Sep 13, 2010 at 04:27, Duncan Sands <baldrick at free.fr> wrote: > Hopefully this is feasible, as I said I didn't work on > it yet. It sounds doable, but I'm not sure why would you want to convert the gimple into LLVM bitcode, if you are already saving LLVM bitcode in the file. Wouldn't you be just duplicating code? Diego.

Hi, In GCC there is one useful option -dp (or -dP for more verbose output) to annotate assembler with instruction patterns, that was used when assembler was generated. For example: double test(long long s) { return s; } gcc -S -dp -O0 test.c test: .LFB0: .cfi_startproc pushq %rbp # 18 *pushdi2_rex64/1 [length = 1] .cfi_def_cfa_offset 16 movq %rsp, %rbp # 19 *movdi_1_rex64/2

On 02.03.2012, at 09:20, Konstantin Vladimirov wrote: > Hi, > > In GCC there is one useful option -dp (or -dP for more verbose output) > to annotate assembler with instruction patterns, that was used when > assembler was generated. For example: The internal "-mllvm -show-mc-inst" option is probably as close as you can get. $ clang -S -O0 test.c -mllvm -show-mc-inst -o

Hi Diego, >> Hopefully this is feasible, as I said I didn't work on >> it yet. > > It sounds doable, but I'm not sure why would you want to convert the > gimple into LLVM bitcode, if you are already saving LLVM bitcode in > the file. Wouldn't you be just duplicating code? here I was thinking of the possibility that some files have been compiled with -flto but

Hi Dmitry, > > In our compiler we use a modified version LLVM Polly, which is very sensitive to > proper code generation. Among the number of limitations, the loop region > (enclosed by phi node on induction variable and branch) is required to be free > of additional memory-dependent branches. In other words, there must be no > conditional "br" instructions below phi

Hi, I have a benchmark (mcf) that is currently slower when compiled with clang compared to gcc 8 (~10%). It seems that a hot loop has a few differences, where one interesting one is that while clang stores an incremented value in each iteration, gcc waits and just stores the final value just once after the loop. The value is a global variable. I wonder if this is something clang does not do

On 01/01/2013 02:45 PM, Duncan Sands wrote: > Hi Dmitry, > >> >> In our compiler we use a modified version LLVM Polly, which is very >> sensitive to >> proper code generation. Among the number of limitations, the loop region >> (enclosed by phi node on induction variable and branch) is required to >> be free >> of additional memory-dependent

Dear all, In our compiler we use a modified version LLVM Polly, which is very sensitive to proper code generation. Among the number of limitations, the loop region (enclosed by phi node on induction variable and branch) is required to be free of additional memory-dependent branches. In other words, there must be no conditional "br" instructions below phi nodes. The problem we are facing

Hi Duncan & Tobi, Thanks a lot for your interest, and for pointing out differences in GIMPLE I missed. Attached is simplified test case. Is it good? Tobi, regarding runtime alias analysis: in KernelGen we already do it along with runtime values substitution. For example: <------------------ __kernelgen_main_loop_17: compile started ---------------------> Integer args substituted:

Dear All, I am trying to understand the process followed for converting GIMPLE IR to LLVM IR in LLVM-GCC/DragonEgg - more importantly conversion of OpenMP extended GIMPLE IR to LLVM IR. It would be great if anybody points me to some documentation before I my-self delve into the understanding of related source code. -- Cheers -mahesha -------------- next part -------------- An HTML attachment

Hi, Thank you, it is just what I need. But... it doesn't work for me: $ clang -S -O0 test.c -mllvm -show-mc-inst error: unknown argument: '-show-mc-inst' $ clang --version clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix May be I need LLVM with higher version, or mention something in configure options? On Fri, Mar 2, 2012 at 4:32 PM,

Hello Duncan Sands, >From your reply, what I can understand is that there is no any new OPENMP specific instructions introduced into LLVM IR as a part of DragonEgg project since GCC has already done the job of lowering OpenMP directives into GOMP runtime library calls at LOW GIMPLE IR level. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

Hi Marcus, > With GCC, it is possible to compile GIMPLE from an object file back to > assembly. With Dragonegg, it seems to be a NOP. (See below for a > comparison.) > > This appears it could be a nice way to mix the strengths of GCC and > LLVM. If it worked.. Should it? I didn't have time to work on LTO with dragonegg yet, but it's on my list of things to do. What

Are you sure this is an alias problem? What is happening is LLVM is leaving the code looking like this: int foo(int *p, volatile int *q, int n) { int i, s = 0; for (i = 0; i < n; ++i) s += *p + *q; return s; } but GCC is changing to code to look like this: int foo(int *p, volatile int *q, int n) { int i, s = 0; int t; t = *p; for (i = 0; i < n; ++i) s += t + *q;

All, If we can speculatively execute a load instruction, why isn’t it safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have

Even if you can't implement such an algorithm sanely, ISTM that auto-generating this code from a table (or whatever), and choosing canonical results (to avoid a fixpoint issue), rather than what seems to be hand-additions of every possible set of minimizations on three variables, is still a better solution, no? At least then you wouldn't have human errors, and a growing file that makes

On Wed, Oct 12, 2011 at 09:40:53AM +0200, Duncan Sands wrote: > Hi Chris, > >>> PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at >>> the following levels: >>> >>> Command line option LLVM optimizers run at >>> ------------------- ---------------------- >>> -O1 tiny amount of

A customer has reported a performance problem, which I have eventually tracked down to the following situation: Consider this program: int foo(int *p, volatile int *q, int n) { int i, s = 0; for (i = 0; i < n; ++i) s += *p + *q; return s; } LLVM's analysis indicates that *p and *q can alias, even though *p is non-volatile whereas *q is volatile. I don't have the