DragonEgg for GCC v8.x and LLVM v6.x is just able to work

Hi LLVM and GCC developers,

My sincere thanks will goto:

* Duncan, the core developer of llvm-gcc and dragonegg http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf

* David, the innovator and developer of GCC https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html

and others who give me kind response for teaching me patiently and carefully about how to migrate GCC v4.8.x to GCC v8.x (git-20170818)

DragonEgg has been migrated to GCC v8.x and LLVM v6.x (svn-r311142), but also able to work for GCC v4.8.x and LLVM v3.3 https://reviews.llvm.org/D35667 and it is just able to work now, for example:

CC=/opt/gcc-git/bin/gcc

LC=/opt/llvm-svn/bin/llvm-config

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$($LC --libdir)

GCC=$CC LLVM_CONFIG=$LC ENABLE_LLVM_PLUGINS=1 DRAGONEGG_DEBUG=1 make -j4

$CC -fplugin=./dragonegg.so \
         -fplugin-arg-dragonegg-debug-pass-arguments \
         -ftime-report \
         -fverbose-asm \
         -fplugin-arg-dragonegg-enable-gcc-optzns \
         -fplugin-arg-dragonegg-emit-ir \
         -S \
         test/hello.c \
         -wrapper gdb,--args

hello.s (LLVM IR, the extension name is not important)

; ModuleID = 'test/hello.c'
source_filename = "test/hello.c"
target triple = "x86_64-redhat-linux"

module asm "\09.ident\09\22GCC: (GNU) 6.4.1 20170727 (Red Hat 6.4.1-1) LLVM: 3.9.1\22"

@__func__.2210 = internal local_unnamed_addr constant [4 x i8] c"foo\00"
@.cst = private local_unnamed_addr constant [24 x i8] c"DEBUG: %s, line %d: %s\0A\00", align 8
@.cst.1 = private local_unnamed_addr constant [13 x i8] c"test/hello.c\00", align 8
@.cst.2 = private local_unnamed_addr constant [12 x i8] c"Leslie Zhai\00", align 8
@.cst.3 = private local_unnamed_addr constant [20 x i8] c"%s: Hello World %d\0A\00", align 8

; Function Attrs: nounwind uwtable
define void @foo(...) unnamed_addr #0 {
entry:
   %"ssa point" = bitcast i32 0 to i32
   br label %"<bb 2>"

"<bb 2>": ; preds = %entry
   %0 = call i32 (i8*, ...) @printf(i8* noalias getelementptr inbounds ([24 x i8], [24 x i8]* @.cst, i64 0, i64 0), [13 x i8]* @.cst.1, i32 4, [4 x i8]* @__func__.2210) #1
   br label %return

return: ; preds = %"<bb 2>"
   ret void
}

declare i32 @printf(i8*, ...)

; Function Attrs: nounwind uwtable
define i32 @main(i32 %argc, i8** %argv) unnamed_addr #0 {
entry:
   %argc_addr = alloca i32, align 4
   %argv_addr = alloca i8**, align 8
   %n = alloca i32
   %s = alloca i8*
   %"<retval>" = alloca i32
   %"alloca point" = bitcast i32 0 to i32
   store i32 %argc, i32* %argc_addr, align 1
   store i8** %argv, i8*** %argv_addr, align 1
   %"ssa point" = bitcast i32 0 to i32
   br label %"<bb 2>"

"<bb 2>": ; preds = %entry
   %0 = call i32 (i8*, ...) @printf(i8* noalias getelementptr inbounds ([20 x i8], [20 x i8]* @.cst.3, i64 0, i64 0), i8* getelementptr inbounds ([12 x i8], [12 x i8]* @.cst.2, i64 0, i64 0), i32 1) #1
   br label %"<L0>"

"<L0>": ; preds = %"<bb 2>"
   store i32 0, i32* %"<retval>", align 1
   br label %return

return: ; preds = %"<L0>"
   %1 = load i32, i32* %"<retval>", align 4
   ret i32 %1
}

attributes #0 = { nounwind uwtable "no-frame-pointer-elim-non-leaf"="true" }
attributes #1 = { nounwind }

!llvm.module.flags = !{!0}

!0 = !{i32 1, !"PIE Level", i32 2}

$ llc hello.s

     .text
     .file "hello.s"
                                         # Start of file scope inline assembly
     .ident "GCC: (GNU) 6.4.1 20170727 (Red Hat 6.4.1-1) LLVM: 3.9.1"

                                         # End of file scope inline assembly
     .globl foo
     .p2align 4, 0x90
     .type foo,@function
foo: # @foo
     .cfi_startproc
# BB#0: # %entry
     pushq %rbp
.Ltmp0:
     .cfi_def_cfa_offset 16
.Ltmp1:
     .cfi_offset %rbp, -16
     movq %rsp, %rbp
.Ltmp2:
     .cfi_def_cfa_register %rbp
     movl $.L.cst, %edi
     movl $.L.cst.1, %esi
     movl $4, %edx
     movl $__func__.2210, %ecx
     xorl %eax, %eax
     callq printf
     popq %rbp
     retq
.Lfunc_end0:
     .size foo, .Lfunc_end0-foo
     .cfi_endproc

     .globl main
     .p2align 4, 0x90
     .type main,@function
main: # @main
     .cfi_startproc
# BB#0: # %entry
     pushq %rbp
.Ltmp3:
     .cfi_def_cfa_offset 16
.Ltmp4:
     .cfi_offset %rbp, -16
     movq %rsp, %rbp
.Ltmp5:
     .cfi_def_cfa_register %rbp
     subq $32, %rsp
     movl %edi, -8(%rbp)
     movq %rsi, -16(%rbp)
     movl $.L.cst.3, %edi
     movl $.L.cst.2, %esi
     movl $1, %edx
     xorl %eax, %eax
     callq printf
     movl $0, -4(%rbp)
     movl -4(%rbp), %eax
     addq $32, %rsp
     popq %rbp
     retq
.Lfunc_end1:
     .size main, .Lfunc_end1-main
     .cfi_endproc

     .type __func__.2210,@object # @__func__.2210
     .section .rodata,"a",@progbits
__func__.2210:
     .asciz "foo"
     .size __func__.2210, 4

     .type .L.cst,@object # @.cst
     .p2align 3
.L.cst:
     .asciz "DEBUG: %s, line %d: %s\n"
     .size .L.cst, 24

     .type .L.cst.1,@object # @.cst.1
     .p2align 3
.L.cst.1:
     .asciz "test/hello.c"
     .size .L.cst.1, 13

     .type .L.cst.2,@object # @.cst.2
     .p2align 3
.L.cst.2:
     .asciz "Leslie Zhai"
     .size .L.cst.2, 12

     .type .L.cst.3,@object # @.cst.3
     .p2align 3
.L.cst.3:
     .asciz "%s: Hello World %d\n"
     .size .L.cst.3, 20

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

$ clang hello.s.s

$ ./a.out

Leslie Zhai: Hello World 1

WIP:

* fix issues https://github.com/xiangzhai/dragonegg/issues

* gengtype not support macro https://gcc.gnu.org/ml/gcc/2017-07/msg00045.html

Hi LLVM and GCC developers,

My sincere thanks will goto:

* Duncan, the core developer of llvm-gcc and dragonegg
http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf

* David, the innovator and developer of GCC
https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html

and others who give me kind response for teaching me patiently and
carefully about how to migrate GCC v4.8.x to GCC v8.x (git-20170818)

DragonEgg has been migrated to GCC v8.x and LLVM v6.x (svn-r311142), but
also able to work for GCC v4.8.x and LLVM v3.3
https://reviews.llvm.org/D35667 and it is just able to work now, for
example:

Very interesting. We are still using dragonegg to process our weather
modeling codes here at ETH / CSCS. Having it updated to work with latest
LLVM will provide us with a current baseline which will also be helpful
to evaluate flang further. Thanks a lot for your effort.

Best,
Tobias

PS: Would be great to have a flang update on the mailing list as well. I
will ask for this in a separate email.

Hi Tobias,

Thanks for your kind response!

Hi LLVM and GCC developers,

My sincere thanks will goto:

* Duncan, the core developer of llvm-gcc and dragonegg
http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf

* David, the innovator and developer of GCC
https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html

and others who give me kind response for teaching me patiently and
carefully about how to migrate GCC v4.8.x to GCC v8.x (git-20170818)

DragonEgg has been migrated to GCC v8.x and LLVM v6.x (svn-r311142), but
also able to work for GCC v4.8.x and LLVM v3.3
https://reviews.llvm.org/D35667 and it is just able to work now, for
example:

Very interesting. We are still using dragonegg to process our weather
modeling codes here at ETH / CSCS. Having it updated to work with latest
LLVM will provide us with a current baseline which will also be helpful
to evaluate flang further. Thanks a lot for your effort.

GIMPLE -> LLVM IR is just able to work, but Target (x86 https://github.com/xiangzhai/dragonegg/tree/master/src/x86 or arm, mips) hasn't been migrated yet, so at present it works as:

GCC Frontend -> GIMPLE -> LLVM IR

so it needs llc for LLVM IR -> Assembly (Target depended)

and I am maintaining AVR Target recently, for example: Migrate to new MCAsmBackend applyFixup and processFixupValue https://reviews.llvm.org/D34551 I am considering how to reuse LLVM's lib/Target for supporting more chipset and write less (Target for DragonEgg) by myself :slight_smile:

Best,
Tobias

PS: Would be great to have a flang update on the mailing list as well. I
will ask for this in a separate email.

I also migrated flang-clang to LLVM 6.0.0svn-r311323 and waiting for rebase the patch https://github.com/flang-compiler/clang/pull/28#issuecomment-323147978

Hi LLVM and GCC developers,

LLVM China http://www.llvm.org.cn forked DragonEgg https://github.com/LLVM-China/dragonegg because:

* Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc and dragonegg). These will be split off from the LLVM project (e.g. to separate Github projects), allowing interested people to continue their development elsewhere. http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

* There are a lot of issues https://github.com/xiangzhai/dragonegg/issues so I need smarter developers' help.

Hi Leslie,

Out of curiosity, what is motivating this work? What is the usecase for dragonegg these days, now that Clang has great C++ support? Are you interested in Ada + LLVM or some other frontend?

-Chris

Dear Chris,

Thanks for your kind response!

The motivating of this work:

1. Clang can not build Linux https://bugs.llvm.org/show_bug.cgi?id=22830 and LLVMLinux patch was not be maintained? http://llvm.linuxfoundation.org/index.php/Main_Page

2. Clang analyzer Frontend can not static analysis glibc or Linux https://bugs.llvm.org/show_bug.cgi?id=31017 but analyzer checker is able to find the bugs for KDE :slight_smile: http://www.leetcode.cn/2016/11/analyzing-code-for-kde-qt-open-source-components.html

3. For leaning GCC plugin, GIMPLE, LLVM IR, GCC PASS, LLVM PASS, CodeGen, etc. from llvm-gcc and dragonegg, thanks for your great job!

The usecase for dragonegg:

1. mips64-linux-gnu-gcc (WIP), arm-linux-gnu-gcc and x86 GCC Frontend -> GIMPLE -> LLVM IR -> Assembly or for KLEE

2. GCC Frontend -> GIMPLE -> Clang AST (WIP)

I am interested in some other frontend, such as flang-clang https://github.com/flang-compiler/clang/pull/28 and it is glad to learn from other developers :slight_smile: https://gcc.gnu.org/ml/gcc/2017-09/msg00022.html