using GCC LTO files as a frontend to dragonegg?

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?

Thanks,

Marcus

[mdaniels@dn002 dragonegg]$ cat hello.c
#include <stdio.h>
int hello () { printf ("Hello World\n"); }
[mdaniels@dn002 dragonegg]$ gcc-4.5 -flto -c hello.c[mdaniels@dn002 dragonegg]$ gcc-4.5 -S -x lto hello.o
[mdaniels@dn002 dragonegg]$ cat hello.s
     .file "hello.o"
     .section .rodata
.LC0:
     .string "Hello World"
     .text
.globl hello
     .type hello, @function
hello:
.LFB0:
     .cfi_startproc
     pushq %rbp
     .cfi_def_cfa_offset 16
     movq %rsp, %rbp
     .cfi_offset 6, -16
     .cfi_def_cfa_register 6
     movl $.LC0, %edi
     call puts
     leave
     .cfi_def_cfa 7, 8
     ret
     .cfi_endproc
.LFE0:
     .size hello, .-hello
     .ident "GCC: (GNU) 4.5.1"
     .section .note.GNU-stack,"",@progbits
[mdaniels@dn002 dragonegg]$ cat hello.c
#include <stdio.h>
int hello () { printf ("Hello World\n"); }
[mdaniels@dn002 dragonegg]$ gcc-4.5 -flto -c hello.c
[mdaniels@dn002 dragonegg]$ rm -f hello.s
[mdaniels@dn002 dragonegg]$ gcc-4.5 -O0 -c -x lto -S hello.o
[mdaniels@dn002 dragonegg]$ cat hello.s
     .file "hello.o"
     .section .rodata
.LC0:
     .string "Hello World"
     .text
.globl hello
     .type hello, @function
hello:
.LFB0:
     .cfi_startproc
     pushq %rbp
     .cfi_def_cfa_offset 16
     movq %rsp, %rbp
     .cfi_offset 6, -16
     .cfi_def_cfa_register 6
     movl $.LC0, %edi
     call puts
     leave
     .cfi_def_cfa 7, 8
     ret
     .cfi_endproc
.LFE0:
     .size hello, .-hello
     .ident "GCC: (GNU) 4.5.1"
     .section .note.GNU-stack,"",@progbits
[mdaniels@dn002 dragonegg]$ rm -f hello.s
[mdaniels@dn002 dragonegg]$ gcc-4.5 -fplugin=./dragonegg.so -c -x lto -flto -S hello.o
[mdaniels@dn002 dragonegg]$ cat hello.s
     .file "hello.o"

     .ident "GCC: (GNU) 4.5.1 LLVM: 113541"

     .section .note.GNU-stack,"",@progbits

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 remember if lot1 (gcc's lto compiler) can load plugins, but if
it can, dragonegg can probably be made to work with it.

But if that is the case, I also don't see much difference in the
result you would get from using dragonegg with the original FE. I
think it plugs itself in the same spot the regular gcc writes its IL
to disk.

Thanks,

Marcus

Cheers,

I see now it works if you ask for the GCC optimizations.. (the last flag)

gcc-4.5 -fplugin=./dragonegg.so -c -x lto -flto -fplugin-arg-dragonegg-emit-ir -S -fplugin-arg-dragonegg-enable-gcc-optzns hello.o

Thanks,

Marcus

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 I would like is: when compiling code with -flto and
dragonegg, LLVM bitcode is recorded alongside the assembler in special ELF
sections, just like gcc stores gimple when -flto is used without dragonegg.
When reading such files with the lto frontend and dragonegg, any gimple gets
turned into LLVM bitcode, and gets combined with any LLVM bitcode read-in
from ELF sections; the combined module is then optimized using LLVM's link
time optimizations. Hopefully this is feasible, as I said I didn't work on
it yet.

Ciao,

Duncan.

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 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 without the dragonegg plugin, so contain gimple in the assembler,
while others have been compiled with dragonegg so contain LLVM bitcode in the
assembler. By converting the gimple into LLVM IR they can all be mutually
optimized together. This might be important if distributions start shipping
standard libraries compiled with -flto.

Ciao,

Duncan.

By the way, the GIMPLE front end (the GCC branch) would seem to be
appealing for use in conjunction with LLVM. The idea being to be able to
select what stages of GCC compilation were compiled. (The front end
appears it is some way off from being usable.)

Marcus

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 without the dragonegg plugin, so contain gimple in the assembler,
while others have been compiled with dragonegg so contain LLVM bitcode in the
assembler. By converting the gimple into LLVM IR they can all be mutually
optimized together. This might be important if distributions start shipping
standard libraries compiled with -flto.

Duncan,
   FYI, all of the dragon-egg targets now fully support lto in current gcc
trunk (since we were able to default lto on for darwin last week).
         Jack

Ah, I see. Yes, that's a good idea.

Diego.

Indeed. Currently, it's only a part-time effort. Perhaps we'll be
ready to merge into trunk by next spring (further follow-ups to gcc@,
please).

Diego.