Re: DWARF64 gcc/clang flag discussion

[Richard Biener via Gcc]

On Thu, Dec 3, 2020 at 6:52 PM David Blaikie  wrote:

>
>
> On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich 
> wrote:
>
>>
>>
>> --
>> *From:* David Blaikie 
>> *Sent:* Wednesday, December 2, 2020 1:12 PM
>> *To:* Alexander Yermolovich 
>> *Cc:* Richard Biener ; Jakub Jelinek <
>> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
>> mask...@google.com 
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>>
>>
>> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich 
>> wrote:
>>
>>
>>
>> --
>> *From:* David Blaikie 
>> *Sent:* Tuesday, December 1, 2020 10:33 AM
>> *To:* Alexander Yermolovich 
>> *Cc:* Richard Biener ; Jakub Jelinek <
>> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
>> mask...@google.com 
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>>
>>
>> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich 
>> wrote:
>>
>>
>>
>> --
>> *From:* David Blaikie 
>> *Sent:* Monday, November 30, 2020 12:09 PM
>> *To:* Alexander Yermolovich 
>> *Cc:* Richard Biener ; Jakub Jelinek <
>> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
>> mask...@google.com 
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
>> wrote:
>>
>> Thank you David for driving the conversation, sorry I was on vacation.
>>
>>
>> All good - really appreciate everyone chipping in whenever/however they
>> can!
>>
>>
>>
>> I guess discussion is from perspective of having both flags
>> gdwarf32/gdwarf64. In which case it's a valid question on whether they
>> should imply -g like -gdwarf-#.
>> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to
>> other debug flags that enable debug information? DWARF spec says that 32bit
>> should be a default, and 64bit should be used rarely (paraphrasing). So
>> when user enabled debug information the default expectation is that it will
>> be 32bit. There is no real need for a flag to say "I want debug
>> information, and I want it 32bit".
>>
>>
>> I'm not quite with you here, I think. I believe it's important to be able
>> to opt into and out of things at any point on the command line - because of
>> how complex build systems build up command lines. You might have a
>> -gdwarf64 set as a project default, but for some reason want to opt into
>> -gdwarf32 in other parts (perhaps you're building the debug info for your
>> interface library you intend to ship to clients who might only have DWARF32
>> support, but your library is big and needs DWARF64 for the rest). A general
>> architectural principle of most command line arguments to the compiler is
>> that they can be opted into/out of fairly symmetrically (hence all the
>> -*no-* variant flags).
>>
>> [Alex] Ah I see, good point.
>>
>>
>> On the other hand, 64bit DWARF format must be enabled. So from users
>> perspective it's "I want debug information enabled for particular DWARF
>> version and level, oh and I want it to be 64bit".
>>
>>
>> But there's also the possibility of wanting to turn on DWARF64 for any
>> debug info in your build, but not necessarily wanting to turn on debug info
>> while doing so. Eg: you have a big build system, with a variety of users
>> and flags all over the place - maybe users opting in to -g2 on some files
>> and -g1 on others, and/or under different build modes. And the project as a
>> whole is reaching the DWARF64 tipping point and you'd like to say "if we're
>> generating DWARF, make it DWARF64". We've recently encountered this sort of
>> situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we
>> had this situation where there's a big code base/build system with many
>> users, many uses of different -gN-type flags and it'd be impractical to go
>> and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we
>> added -fdebug-default-version=N (I might be misremembering the spelling) to
>> Clang to support this use case of "If we're generating DWARF, make it
>> DWARFv5")
>>
>> [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable
>> debug generation, but if it is enabled it will be 64bit. A "qualifier" of
>> sorts.
>>
>>
>> OK. My concern there, though I think it's the preferable semantics for
>> the -gdwarf64 flag when considered in isolation, is now -gdwarf64 and
>> -gdwarf-5 would have some fairly subtly different semantics (the latter
>> enables debug info and the former does not) in contrast to how close their
>> spelling is. (in addition to their general similarly maybe being a source
>> of confusion - even if the numbers aren't close to each other)
>> [Alex] That is a good point, but I guess broader question is if
>> precedence is not good, should we follow it? If it's clearly documented,
>> might be OK. As my professor Brian Harvey

Re: Help with PR97872

[Prathamesh Kulkarni via Gcc]

On Thu, 3 Dec 2020 at 16:35, Richard Biener  wrote:
>
> On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Tue, 1 Dec 2020 at 16:39, Richard Biener  wrote:
> > >
> > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > Hi,
> > > > For the test mentioned in PR, I was trying to see if we could do
> > > > specialized expansion for vcond in target when operands are -1 and 0.
> > > > arm_expand_vcond gets the following operands:
> > > > (reg:V8QI 113 [ _2 ])
> > > > (reg:V8QI 117)
> > > > (reg:V8QI 118)
> > > > (lt (reg/v:V8QI 115 [ a ])
> > > > (reg/v:V8QI 116 [ b ]))
> > > > (reg/v:V8QI 115 [ a ])
> > > > (reg/v:V8QI 116 [ b ])
> > > >
> > > > where r117 and r118 are set to vector constants -1 and 0 respectively.
> > > > However, I am not sure if there's a way to check if the register is
> > > > constant during expansion time (since we don't have df analysis yet) ?
> > > >
> > > > Alternatively, should we add a target hook that returns true if the
> > > > result of vector comparison is set to all-ones or all-zeros, and then
> > > > use this hook in gimple ISEL to effectively turn VEC_COND_EXPR into nop 
> > > > ?
> > >
> > > Would everything match-up for a .VEC_CMP IFN producing a non-mask
> > > vector type?  ISEL could special case the a ? -1 : 0 case this way.
> > I think the vec_cmp pattern matches but it produces a masked vector type.
> > In the attached patch, I simply replaced:
> > _1 = a < b
> > x = _1 ? -1 : 0
> > with
> > x = view_convert_expr<_1>
> >
> > For the test-case, isel generates:
> >   vector(8)  _1;
> >   vector(8) signed char _2;
> >   uint8x8_t _5;
> >
> >[local count: 1073741824]:
> >   _1 = a_3(D) < b_4(D);
> >   _2 = VIEW_CONVERT_EXPR(_1);
> >   _5 = VIEW_CONVERT_EXPR(_2);
> >   return _5;
> >
> > and results in desired code-gen:
> > f1:
> > vcgt.s8 d0, d1, d0
> > bx  lr
> >
> > Altho I guess, we should remove the redundant conversions during isel 
> > itself ?
> > and result in:
> > _1 = a_3(D) < b_4(D)
> > _5 = VIEW_CONVERT_EXPR(_1)
> >
> > (Patch is lightly tested with only vect.exp)
>
> +  /* For targets where result of comparison is all-ones or all-zeros,
> + a < b ? -1 : 0 can be reduced to a < b.  */
> +
> +  if (integer_minus_onep (op1) && integer_zerop (op2))
> +{
>
> So this really belongs here:
>
>   tree op0_type = TREE_TYPE (op0);
>   tree op0a_type = TREE_TYPE (op0a);
>
> <---
>
>   if (used_vec_cond_exprs >= 2
>   && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
>   != CODE_FOR_nothing)
>   && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> {
>
>
> +  gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT (op0));
> +  tree op0a = gimple_assign_rhs1 (def_stmt);
> +  tree op0_type = TREE_TYPE (op0);
> +  tree op0a_type = TREE_TYPE (op0a);
> +  enum tree_code tcode = gimple_assign_rhs_code (def_stmt);
> +
> +  if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> +   {
> + tree conv_op = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs), op0);
> + gassign *new_stmt = gimple_build_assign (lhs, conv_op);
> + gsi_replace (gsi, new_stmt, true);
>
> and you need to verify that the mode of the lhs and the mode of op0
> agree and that the target can actually expand_vec_cmp_expr_p
Thanks for the suggestions, does the attached patch look OK ?
Sorry, I am not sure how to check if target can actually expand vec_cmp ?
I assume that since expand_vec_cmp_expr_p queries optab and if it gets
a valid cmp icode, that
should be sufficient ?

Thanks,
Prathamesh
>
> Richard.
>
>
>
> > Thanks,
> > Prathamesh
> > >
> > > > Thanks,
> > > > Prathamesh
> > > >
> > >
> > > --
> > > Richard Biener 
> > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> > > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
> >
>
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


pr97282-2.diff
Description: Binary data

Re: Help with PR97872

[Richard Biener]

On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:

> On Thu, 3 Dec 2020 at 16:35, Richard Biener  wrote:
> >
> > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 1 Dec 2020 at 16:39, Richard Biener  wrote:
> > > >
> > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > >
> > > > > Hi,
> > > > > For the test mentioned in PR, I was trying to see if we could do
> > > > > specialized expansion for vcond in target when operands are -1 and 0.
> > > > > arm_expand_vcond gets the following operands:
> > > > > (reg:V8QI 113 [ _2 ])
> > > > > (reg:V8QI 117)
> > > > > (reg:V8QI 118)
> > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > (reg/v:V8QI 116 [ b ]))
> > > > > (reg/v:V8QI 115 [ a ])
> > > > > (reg/v:V8QI 116 [ b ])
> > > > >
> > > > > where r117 and r118 are set to vector constants -1 and 0 respectively.
> > > > > However, I am not sure if there's a way to check if the register is
> > > > > constant during expansion time (since we don't have df analysis yet) ?
> > > > >
> > > > > Alternatively, should we add a target hook that returns true if the
> > > > > result of vector comparison is set to all-ones or all-zeros, and then
> > > > > use this hook in gimple ISEL to effectively turn VEC_COND_EXPR into 
> > > > > nop ?
> > > >
> > > > Would everything match-up for a .VEC_CMP IFN producing a non-mask
> > > > vector type?  ISEL could special case the a ? -1 : 0 case this way.
> > > I think the vec_cmp pattern matches but it produces a masked vector type.
> > > In the attached patch, I simply replaced:
> > > _1 = a < b
> > > x = _1 ? -1 : 0
> > > with
> > > x = view_convert_expr<_1>
> > >
> > > For the test-case, isel generates:
> > >   vector(8)  _1;
> > >   vector(8) signed char _2;
> > >   uint8x8_t _5;
> > >
> > >[local count: 1073741824]:
> > >   _1 = a_3(D) < b_4(D);
> > >   _2 = VIEW_CONVERT_EXPR(_1);
> > >   _5 = VIEW_CONVERT_EXPR(_2);
> > >   return _5;
> > >
> > > and results in desired code-gen:
> > > f1:
> > > vcgt.s8 d0, d1, d0
> > > bx  lr
> > >
> > > Altho I guess, we should remove the redundant conversions during isel 
> > > itself ?
> > > and result in:
> > > _1 = a_3(D) < b_4(D)
> > > _5 = VIEW_CONVERT_EXPR(_1)
> > >
> > > (Patch is lightly tested with only vect.exp)
> >
> > +  /* For targets where result of comparison is all-ones or all-zeros,
> > + a < b ? -1 : 0 can be reduced to a < b.  */
> > +
> > +  if (integer_minus_onep (op1) && integer_zerop (op2))
> > +{
> >
> > So this really belongs here:
> >
> >   tree op0_type = TREE_TYPE (op0);
> >   tree op0a_type = TREE_TYPE (op0a);
> >
> > <---
> >
> >   if (used_vec_cond_exprs >= 2
> >   && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
> >   != CODE_FOR_nothing)
> >   && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > {
> >
> >
> > +  gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT (op0));
> > +  tree op0a = gimple_assign_rhs1 (def_stmt);
> > +  tree op0_type = TREE_TYPE (op0);
> > +  tree op0a_type = TREE_TYPE (op0a);
> > +  enum tree_code tcode = gimple_assign_rhs_code (def_stmt);
> > +
> > +  if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > +   {
> > + tree conv_op = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs), op0);
> > + gassign *new_stmt = gimple_build_assign (lhs, conv_op);
> > + gsi_replace (gsi, new_stmt, true);
> >
> > and you need to verify that the mode of the lhs and the mode of op0
> > agree and that the target can actually expand_vec_cmp_expr_p
> Thanks for the suggestions, does the attached patch look OK ?
> Sorry, I am not sure how to check if target can actually expand vec_cmp ?
> I assume that since expand_vec_cmp_expr_p queries optab and if it gets
> a valid cmp icode, that
> should be sufficient ?

Yes

> Thanks,
> Prathamesh
> >
> > Richard.
> >
> >
> >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > > Thanks,
> > > > > Prathamesh
> > > > >
> > > >
> > > > --
> > > > Richard Biener 
> > > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> > > > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
> > >
> >
> > --
> > Richard Biener 
> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?

[Maciej W. Rozycki]

On Mon, 30 Nov 2020, Jeff Law via Gcc wrote:

> > Ping.  Anybody got an opinion on the approach we should take?
> Could we set warning_threshold to a value to inhibit this behavior
> completely.  It seems backwards to me that warnings have this effect.

 Sounds like rate-limiting of some sort to me.  It may be worth enquiring 
at , maybe Rob remembers what this was meant for.

  Maciej

Re: DWARF64 gcc/clang flag discussion

[Alexander Yermolovich via Gcc]

From: Richard Biener 
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie 
Cc: Alexander Yermolovich ; Jakub Jelinek ; 
Mark Wielaard ; gcc@gcc.gnu.org ; 
ikud...@accesssoftek.com ; mask...@google.com 

Subject: Re: DWARF64 gcc/clang flag discussion

On Thu, Dec 3, 2020 at 6:52 PM David Blaikie 
mailto:dblai...@gmail.com>> wrote:


On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich 
mailto:ayerm...@fb.com>> wrote:



From: David Blaikie mailto:dblai...@gmail.com>>
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich mailto:ayerm...@fb.com>>
Cc: Richard Biener 
mailto:richard.guent...@gmail.com>>; Jakub Jelinek 
mailto:ja...@redhat.com>>; Mark Wielaard 
mailto:m...@klomp.org>>; 
gcc@gcc.gnu.org 
mailto:gcc@gcc.gnu.org>>; 
ikud...@accesssoftek.com 
mailto:ikud...@accesssoftek.com>>; 
mask...@google.com 
mailto:mask...@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion



On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich 
mailto:ayerm...@fb.com>> wrote:



From: David Blaikie mailto:dblai...@gmail.com>>
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich mailto:ayerm...@fb.com>>
Cc: Richard Biener 
mailto:richard.guent...@gmail.com>>; Jakub Jelinek 
mailto:ja...@redhat.com>>; Mark Wielaard 
mailto:m...@klomp.org>>; 
gcc@gcc.gnu.org 
mailto:gcc@gcc.gnu.org>>; 
ikud...@accesssoftek.com 
mailto:ikud...@accesssoftek.com>>; 
mask...@google.com 
mailto:mask...@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion



On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich 
mailto:ayerm...@fb.com>> wrote:



From: David Blaikie mailto:dblai...@gmail.com>>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich mailto:ayerm...@fb.com>>
Cc: Richard Biener 
mailto:richard.guent...@gmail.com>>; Jakub Jelinek 
mailto:ja...@redhat.com>>; Mark Wielaard 
mailto:m...@klomp.org>>; 
gcc@gcc.gnu.org 
mailto:gcc@gcc.gnu.org>>; 
ikud...@accesssoftek.com 
mailto:ikud...@accesssoftek.com>>; 
mask...@google.com 
mailto:mask...@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
mailto:ayerm...@fb.com>> wrote:
Thank you David for driving the conversation, sorry I was on vacation.

All good - really appreciate everyone chipping in whenever/however they can!


I guess discussion is from perspective of having both flags gdwarf32/gdwarf64. 
In which case it's a valid question on whether they should imply -g like 
-gdwarf-#.
But can this be viewed as only a -gdwarf64 flag, that is a qualifier to other 
debug flags that enable debug information? DWARF spec says that 32bit should be 
a default, and 64bit should be used rarely (paraphrasing). So when user enabled 
debug information the default expectation is that it will be 32bit. There is no 
real need for a flag to say "I want debug information, and I want it 32bit".

I'm not quite with you here, I think. I believe it's important to be able to 
opt into and out of things at any point on the command line - because of how 
complex build systems build up command lines. You might have a -gdwarf64 set as 
a project default, but for some reason want to opt into -gdwarf32 in other 
parts (perhaps you're building the debug info for your interface library you 
intend to ship to clients who might only have DWARF32 support, but your library 
is big and needs DWARF64 for the rest). A general architectural principle of 
most command line arguments to the compiler is that they can be opted into/out 
of fairly symmetrically (hence all the -*no-* variant flags).

[Alex] Ah I see, good point.

On the other hand, 64bit DWARF format must be enabled. So from users 
perspective it's "I want debug information enabled for particular DWARF version 
and level, oh and I want it to be 64bit".

But there's also the possibility of wanting to turn on DWARF64 for any debug 
info in your build, but not necessarily wanting to turn on debug info while 
doing so. Eg: you have a big build system, with a variety of users and flags 
all over the place - maybe users opting in to -g2 on some files and -g1 on 
others, and/or under different build modes. And the project as a whole is 
reaching the DWARF64 tipping point and you'd like to say "if we're generating 
DWARF, make it DWARF64". We've recently encountered this sort of situation with 
-gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we had this situation 
where there's a big code base/build system with many users, many uses of 
different -gN-type flags and it'd be impractical to go and add -gdwarf-5 to all 
the -gN uses to make them all use DWARFv5, so we added 

gcc-9-20201204 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20201204 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20201204/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 34e72e050bf4e23689af7061f6381b95339eb7fa

You'll find:

 gcc-9-20201204.tar.xzComplete GCC

  SHA256=a47b5cd6a5dd0dbc837b2d990dee4e6452789c2d34178cb500c402c36d22aeda
  SHA1=383de211f23cac512a047ed9a18b7dc494522fba

Diffs from 9-20201127 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

how to get the library DECL for a built-in function

[Martin Sebor via Gcc]

I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL.  Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?

In C, what I'm looking for appears to be DECL_CHAIN(decl), at
least for the example I looked at.  I.e., the library libdecl
for a corresponding __bultin_xxx DECL is DECL_CHAIN (DECL).

But in C++, it looks like it's the other way around and it's
the built-in decl that's the DECL_CHAIN(DECL) for the built-in
DECL, and AFAIK there's no good way to get from the latter to
the former.

Thanks
Martin

Re: how to get the library DECL for a built-in function

[Martin Sebor via Gcc]

On 12/4/20 4:33 PM, Martin Sebor wrote:

I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL.  Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?

In C, what I'm looking for appears to be DECL_CHAIN(decl), at
least for the example I looked at.  I.e., the library libdecl
for a corresponding __bultin_xxx DECL is DECL_CHAIN (DECL).

But in C++, it looks like it's the other way around and it's
the built-in decl that's the DECL_CHAIN(DECL) for the built-in
DECL, and AFAIK there's no good way to get from the latter to
the former.


To expand on this: I expected to get the library DECL for
a declared function by calling
symtab_node::get_from_asmname(libname) like for instance:

  tree id = get_identifier ("free");
  symtab_node *node = symtab_node::get_from_asmname (id);

but what I get back is a DECL for __builtin_free instead.
The DECL for "free" is the result of DECL_CHAIN() in C but
not in C++.



Thanks
Martin