Re: [llvm-dev] DragonEgg for GCC v8.x and LLVM v6.x is just able to work
On Mon, Aug 21, 2017, at 05:31, Leslie Zhai via llvm-dev wrote:
> 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.
>
>
> $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 %""
>
> "": ; 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 = %""
>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*
>%"" = 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 %""
>
> "": ; 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 %""
>
> "": ; preds = %""
>store i32 0, i32* %"", align 1
>br label %return
>
> return: ; preds = %""
>%1 = load i32, i32* %"", 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
> .globlfoo
> .p2align4, 0x90
> .typefoo,@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
> callqprintf
> popq%rbp
> retq
> .Lfunc_end0:
> .sizefoo, .Lfunc_end0-foo
> .cfi_endproc
>
> .globlmain
> .p2align4, 0x90
> .typemain,@function
> main:
Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF
On Fri, 12 May 2017, Richard Biener wrote: > > This is a heads-up that I am in the process of implementing the last > of Jasons review comments on the dwarf2out parts of early LTO debug > support. I hope to post final patches early next week after thoroughly > re-testing everything. > > Note that Mach-O and [X]COFF support in the simple-object machinery > is still missing for the early LTO debug feature so I am going to > break LTOing with DWARF debuginfo on Darwin and Windows (CCing > maintainers). Mach-O support has been worked on a bit by Iain > and myself but the simple-object piece is still missing. > A workaround is to use stabs on these targets with LTO. > > DWARF part: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01023.html > simple-object part: > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01733.html > > both still apply with some fuzz. The patches have been applied now (r251220). You'll see -flto -g testcases on the above archs fail (I'm still curious how exactly). There's going to be a "workaround" I plan to apply no earlier than stage3, it will effectively force -g0 on those targets when you use DWARF. Seeing the FAILs might be enough hunch to look into the (small) task of implementing the simple-object implementation of simple_object_copy_lto_debug_sections for your object format. Richard.
Re: wi::max_value() of a boolean is not 1
The attached patch fixes the problem by sign extending before
constructing the wide int. It does so while constructing the
hwi_with_prec object, since the int_traits
container has is_sign_extended=true, so I assume the underlying
hwi_with_prec must be stored with sign extension.
Is this what you had in mind, or would you prefer the sign extension
in the wi::int_traits decompose routine?
Or somewhere else entirely ;-).
Thanks.
Aldy
On Sun, Aug 20, 2017 at 6:40 AM, Richard Biener
wrote:
> On August 20, 2017 10:46:54 AM GMT+02:00, Aldy Hernandez
> wrote:
>>Hi folks.
>>
>>Calling wi::max_value() of a boolean_type creates a wide_int with all
>>bits set, not just the least significant bit.
>>
>>tree type = boolean_type_node;
>>wide_int x = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
>>(gdb) print x.dump()
>>[0x], precision = 1
>>
>>However, one can also create a boolean of true with:
>>
>>wide_int one = wi::uhwi (1, TYPE_PRECISION (boolean_type_node));
>>(gdb) print one.dump()
>>[0x1], precision = 1
>
> Looks like this one fails to be sign extended.
> Richard.
>
>>These will not be equal to each other because wi::eq_p() will only
>>strip
>>off excess bits when . However,
>>is_sign_extended=true for all wide_int's.
>>
>>Am I doing something wrong?
>>
>>Could I change wi::max_value() to strip off excess bits, instead of
>>setting all bits like it's currently doing:
>>
>>wide_int
>>wi::max_value (unsigned int precision, signop sgn)
>>{
>> gcc_checking_assert (precision != 0);
>> if (sgn == UNSIGNED)
>> /* The unsigned max is just all ones. */
>> return shwi (-1, precision);
>>...
>>...
>>
>>Or perhaps change wi::eq_p() to strip off excess bits?
>>
>>Or am I missing something else entirely?
>>Aldy
>
curr
Description: Binary data
Re: wi::max_value() of a boolean is not 1
On August 21, 2017 5:43:08 PM GMT+02:00, Aldy Hernandez
wrote:
>The attached patch fixes the problem by sign extending before
>constructing the wide int. It does so while constructing the
>hwi_with_prec object, since the int_traits
>container has is_sign_extended=true, so I assume the underlying
>hwi_with_prec must be stored with sign extension.
>
>Is this what you had in mind, or would you prefer the sign extension
>in the wi::int_traits decompose routine?
>
>Or somewhere else entirely ;-).
Richard?
>Thanks.
>Aldy
>
>On Sun, Aug 20, 2017 at 6:40 AM, Richard Biener
> wrote:
>> On August 20, 2017 10:46:54 AM GMT+02:00, Aldy Hernandez
> wrote:
>>>Hi folks.
>>>
>>>Calling wi::max_value() of a boolean_type creates a wide_int with all
>>>bits set, not just the least significant bit.
>>>
>>>tree type = boolean_type_node;
>>>wide_int x = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
>>>(gdb) print x.dump()
>>>[0x], precision = 1
>>>
>>>However, one can also create a boolean of true with:
>>>
>>>wide_int one = wi::uhwi (1, TYPE_PRECISION (boolean_type_node));
>>>(gdb) print one.dump()
>>>[0x1], precision = 1
>>
>> Looks like this one fails to be sign extended.
>> Richard.
>>
>>>These will not be equal to each other because wi::eq_p() will only
>>>strip
>>>off excess bits when . However,
>>>is_sign_extended=true for all wide_int's.
>>>
>>>Am I doing something wrong?
>>>
>>>Could I change wi::max_value() to strip off excess bits, instead of
>>>setting all bits like it's currently doing:
>>>
>>>wide_int
>>>wi::max_value (unsigned int precision, signop sgn)
>>>{
>>> gcc_checking_assert (precision != 0);
>>> if (sgn == UNSIGNED)
>>> /* The unsigned max is just all ones. */
>>> return shwi (-1, precision);
>>>...
>>>...
>>>
>>>Or perhaps change wi::eq_p() to strip off excess bits?
>>>
>>>Or am I missing something else entirely?
>>>Aldy
>>
Re: wi::max_value() of a boolean is not 1
Richard Biener writes:
> On August 21, 2017 5:43:08 PM GMT+02:00, Aldy Hernandez
> wrote:
>>The attached patch fixes the problem by sign extending before
>>constructing the wide int. It does so while constructing the
>>hwi_with_prec object, since the int_traits
>>container has is_sign_extended=true, so I assume the underlying
>>hwi_with_prec must be stored with sign extension.
>>
>>Is this what you had in mind, or would you prefer the sign extension
>>in the wi::int_traits decompose routine?
>>
>>Or somewhere else entirely ;-).
>
> Richard?
Think it should be "<" rather than "<=". LGTM with that change, thanks.
Richard
>>Thanks.
>>Aldy
>>
>>On Sun, Aug 20, 2017 at 6:40 AM, Richard Biener
>> wrote:
>>> On August 20, 2017 10:46:54 AM GMT+02:00, Aldy Hernandez
>> wrote:
Hi folks.
Calling wi::max_value() of a boolean_type creates a wide_int with all
bits set, not just the least significant bit.
tree type = boolean_type_node;
wide_int x = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
(gdb) print x.dump()
[0x], precision = 1
However, one can also create a boolean of true with:
wide_int one = wi::uhwi (1, TYPE_PRECISION (boolean_type_node));
(gdb) print one.dump()
[0x1], precision = 1
>>>
>>> Looks like this one fails to be sign extended.
>>> Richard.
>>>
These will not be equal to each other because wi::eq_p() will only
strip
off excess bits when . However,
is_sign_extended=true for all wide_int's.
Am I doing something wrong?
Could I change wi::max_value() to strip off excess bits, instead of
setting all bits like it's currently doing:
wide_int
wi::max_value (unsigned int precision, signop sgn)
{
gcc_checking_assert (precision != 0);
if (sgn == UNSIGNED)
/* The unsigned max is just all ones. */
return shwi (-1, precision);
...
...
Or perhaps change wi::eq_p() to strip off excess bits?
Or am I missing something else entirely?
Aldy
>>>
Invoice issue
Hello , Your phone number was unavailable for some reason today. Can you please provide me with the status of this unpaid invoice? http://temasek.co/Invoice-12425-Message/ Thanks, xen-devel-boun...@lists.xen.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. == Pursuant to North Carolina General Statutes Chapter 132, Public Records, this electronic mail message and any attachments hereto, as well as any electronic mail message(s) that may be sent in response to it may be considered public record and as such are subject to request and review by third parties. ==
