[GSoC] Question about Relatively Simple Library Traits

[Ken Matsui via Gcc]

Hi,

I am working on the GSoC project, "C++: Implement compiler built-in
traits for the standard library traits". I found the following library
traits that I am not sure if implementing built-in traits brings
reasonable speed up.

* std::is_fundamental
* std::is_arithmetic
* std::is_scalar
* std::is_object
* std::is_compound
* std::is_scoped_enum

For example, std::is_object has no template specializations, but its
inheriting class looks complicated.

__not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type

If we define the built-in trait for this trait, we have: (as
equivalence of the above code)

__bool_constant<__is_object(_Tp)>

And __is_object built-in trait should be like:

!(type1 == FUNCTION_TYPE || type1 == ...)

In this case, could someone tell me which one would be faster? Or, is
there no other way to know which but to benchmark?

Sincerely,
Ken Matsui

Re: [GSoC] Question about Relatively Simple Library Traits

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023 at 09:58, Jonathan Wakely  wrote:
>
> On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc  wrote:
> >
> > Hi,
> >
> > I am working on the GSoC project, "C++: Implement compiler built-in
> > traits for the standard library traits". I found the following library
> > traits that I am not sure if implementing built-in traits brings
> > reasonable speed up.
> >
> > * std::is_fundamental
> > * std::is_arithmetic
> > * std::is_scalar
> > * std::is_object
> > * std::is_compound
> > * std::is_scoped_enum
> >
> > For example, std::is_object has no template specializations, but its
> > inheriting class looks complicated.
> >
> > __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type
> >
> > If we define the built-in trait for this trait, we have: (as
> > equivalence of the above code)
> >
> > __bool_constant<__is_object(_Tp)>
> >
> > And __is_object built-in trait should be like:
> >
> > !(type1 == FUNCTION_TYPE || type1 == ...)
> >
> > In this case, could someone tell me which one would be faster? Or, is
> > there no other way to know which but to benchmark?
>
> You should benchmark it anyway, I was always expecting that to be a
> part of this GSoC project :-)
>
> But is_object is NOT a "relatively simple" trait. What you show above
> is very complex. One of the more complex traits we have. Partial
> specializations are quite fast to match (in general) so eliminating
> partial speclializations (e.g. like we have for is_const) should not
> be the goal.
>
> For is_object we instantiate:
>
> is_function
> is_const
> is_reference
> is_void
> __bool_constant
> __or_
> __not_
> __bool_constant
>
> This is a ton of work! Instantiating class templates is the slowest
> part of trait evaluation, not matching partial specializations.

And then if the same program also instantiates is_object (without
the const), then currently we instantiate:

is_function
is_const
is_reference
is_void
__bool_constant
__or_
__not_
__bool_constant

The first four instantiations are not shared with is_object, so we have to instantiate them anew. The last four are common
with is_object so don't need to be instantiated again, the
compiler will have cached those instantiations.
But if the same program also uses is_object then we have another
four new instantiations to generate. And another four for
is_object. And another four for is_object etc.
etc.

With a built-in they will all use __bool_constant and nothing
else (apart from the top-level is_object specialization itself,
which is unavoidable* since that's the trait actually being
evaluated).

* In fact, it's not really unavoidable, MSVC avoids it entirely. Their
compiler pattern matches the standard traits and never even
instantiates them, so every use of is_object::value gets expanded
directly to __is_object(T) without instantiating anything. We don't do
that, and if we just replace turn 8 or 9 class template instantiations
into 1 then we'll be doing great.

Re: [GSoC] Question about Relatively Simple Library Traits

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc  wrote:
>
> Hi,
>
> I am working on the GSoC project, "C++: Implement compiler built-in
> traits for the standard library traits". I found the following library
> traits that I am not sure if implementing built-in traits brings
> reasonable speed up.
>
> * std::is_fundamental
> * std::is_arithmetic
> * std::is_scalar
> * std::is_object
> * std::is_compound
> * std::is_scoped_enum
>
> For example, std::is_object has no template specializations, but its
> inheriting class looks complicated.
>
> __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type
>
> If we define the built-in trait for this trait, we have: (as
> equivalence of the above code)
>
> __bool_constant<__is_object(_Tp)>
>
> And __is_object built-in trait should be like:
>
> !(type1 == FUNCTION_TYPE || type1 == ...)
>
> In this case, could someone tell me which one would be faster? Or, is
> there no other way to know which but to benchmark?

You should benchmark it anyway, I was always expecting that to be a
part of this GSoC project :-)

But is_object is NOT a "relatively simple" trait. What you show above
is very complex. One of the more complex traits we have. Partial
specializations are quite fast to match (in general) so eliminating
partial speclializations (e.g. like we have for is_const) should not
be the goal.

For is_object we instantiate:

is_function
is_const
is_reference
is_void
__bool_constant
__or_
__not_
__bool_constant

This is a ton of work! Instantiating class templates is the slowest
part of trait evaluation, not matching partial specializations.

A built-in for __is_object will mean we only instantiate
__bool_constant. That will be MUCH faster. But I think it would
be a good idea for you to benchmark it to confirm that.

Re: [GSoC] Question about Relatively Simple Library Traits

[Ken Matsui via Gcc]

On Fri, Mar 24, 2023 at 3:06 AM Jonathan Wakely  wrote:
>
> On Fri, 24 Mar 2023 at 09:58, Jonathan Wakely  wrote:
> >
> > On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc  wrote:
> > >
> > > Hi,
> > >
> > > I am working on the GSoC project, "C++: Implement compiler built-in
> > > traits for the standard library traits". I found the following library
> > > traits that I am not sure if implementing built-in traits brings
> > > reasonable speed up.
> > >
> > > * std::is_fundamental
> > > * std::is_arithmetic
> > > * std::is_scalar
> > > * std::is_object
> > > * std::is_compound
> > > * std::is_scoped_enum
> > >
> > > For example, std::is_object has no template specializations, but its
> > > inheriting class looks complicated.
> > >
> > > __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type
> > >
> > > If we define the built-in trait for this trait, we have: (as
> > > equivalence of the above code)
> > >
> > > __bool_constant<__is_object(_Tp)>
> > >
> > > And __is_object built-in trait should be like:
> > >
> > > !(type1 == FUNCTION_TYPE || type1 == ...)
> > >
> > > In this case, could someone tell me which one would be faster? Or, is
> > > there no other way to know which but to benchmark?
> >
> > You should benchmark it anyway, I was always expecting that to be a
> > part of this GSoC project :-)
> >
> > But is_object is NOT a "relatively simple" trait. What you show above
> > is very complex. One of the more complex traits we have. Partial
> > specializations are quite fast to match (in general) so eliminating
> > partial speclializations (e.g. like we have for is_const) should not
> > be the goal.
> >
> > For is_object we instantiate:
> >
> > is_function
> > is_const
> > is_reference
> > is_void
> > __bool_constant
> > __or_
> > __not_
> > __bool_constant
> >
> > This is a ton of work! Instantiating class templates is the slowest
> > part of trait evaluation, not matching partial specializations.
>
> And then if the same program also instantiates is_object (without
> the const), then currently we instantiate:
>
> is_function
> is_const
> is_reference
> is_void
> __bool_constant
> __or_
> __not_
> __bool_constant
>
> The first four instantiations are not shared with is_object int>, so we have to instantiate them anew. The last four are common
> with is_object so don't need to be instantiated again, the
> compiler will have cached those instantiations.
> But if the same program also uses is_object then we have another
> four new instantiations to generate. And another four for
> is_object. And another four for is_object etc.
> etc.
>
> With a built-in they will all use __bool_constant and nothing
> else (apart from the top-level is_object specialization itself,
> which is unavoidable* since that's the trait actually being
> evaluated).
>
> * In fact, it's not really unavoidable, MSVC avoids it entirely. Their
> compiler pattern matches the standard traits and never even
> instantiates them, so every use of is_object::value gets expanded
> directly to __is_object(T) without instantiating anything. We don't do
> that, and if we just replace turn 8 or 9 class template instantiations
> into 1 then we'll be doing great.

Thank you so much for your detailed explanation! I totally did not
understand well what class templates were doing! (And yes, I need to
prepare my environment to take benchmarks...)

So, do we expect to have __is_object built-in trait? Since
std::is_object is a combination of multiple traits, would doing the
following be the best implementation over implementing __is_object(T)?
(you told me that built-ins make the compiler slightly bigger and
slower)

__bool_constant

This would instantiate only __bool_constant and
__bool_constant, which can be mostly shared, and we can also
avoid adding an additional built-in.

Sincerely,
Ken Matsui

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

[Martin Jambor]

Hi,

On Sat, Mar 18 2023, Arsen Arsenović wrote:
> Martin Jambor  writes:

[...]

>>>
>>> For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
>>> seems to try to remove an unreachable function that was already inlined
>>> into a different unreachable function.
>>
>> No, it fails to remove it.  It is still there but should not have been,
>> that is the problem.
>
> Ah - I see.
>
>>>
>>> This decision later trips up the gcc_assert in:
>>>
>>>   /* Inline clones might be kept around so their materializing allows 
>>> further
>>>  cloning.  If the function the clone is inlined into is removed, we need
>>>  to turn it into normal cone.  */
>>>   FOR_EACH_FUNCTION (node)
>>> {
>>>   if (node->inlined_to
>>>   && !node->callers)
>>> {
>>>   gcc_assert (node->clones);
>>>   node->inlined_to = NULL;
>>>   update_inlined_to_pointer (node, node);
>>> }
>>>   node->aux = NULL;
>>> }
>>>
>>> .. because it is expecting that an inlined function without callers
>>> (which is necessarily true here as this function is unreachable and so
>>> was ->remove ()'d earlier) has clones.
>>
>> The assert makes sure that if we encounter an inlined-to node without
>> any caller, that it merely holds as the holder of the function body for
>> its other specialized (think IPA-CP) or inline clones.  If node->clones
>> is false, there are no such clones and it was a bug to mark the node as
>> required during the removal of unreachable nodes.
>
> I see.  That makes sense.  So, this assert is placed here by convenience
> rather than being this invariant being absolutely required for the
> purpose of the loop?  (it is related, so this placement makes sense, I
> just want to confirm whether it's a "mandatory" invariant)

If the assert fails, the algorithm does not work as intended.  OTOH, It
could be a gcc_checking_assert only since user compiled code would still
work, just would be unnecessarily bigger.

>
>>>
>>> Either removing the assertion or making clone_inline_nodes clone when
>>> there are no existing clones 'fixes' (suppresses, but I haven't verified
>>> whether the results are correct) the problem.
>>>
>>> Is this gcc_assert correct in that an inlined function without callers
>>> necessarily must have clones?
>>
>> It is correct.  An inlined function without a caller is even a logical
>> oxymoron and can only exist if it has the purpose described above (and
>> even then probably only in a fairly special circumstances).
>
> Right.  I wasn't quite sure whether setting inlined_to would remove that
> caller, but if I understood right, it should not.
>
> What is interesting, though, is that there is an attempt to remove this
> node during ipa_inline:

IPA-inline calls remove_unreachable_nodes to get rid of call graph nodes
which are known not to be necessary after inlining (inlining can lead to
redirection of some call graph edges to __builtin_unreachable) and
unreachable removal... well.. removes nodes.

>
>  (gdb) bt
>  #0  cgraph_edge::remove_callee (
>  this=  "__ct_base "/18> -> )>)
>  at ../../gcc/gcc/cgraph.h:3299
>  #1 0x00d03c37 in cgraph_node::remove_callees (this=   * const 0x76dedaa0 "__ct_base "/18>) at
>   ../../gcc/gcc/cgraph.cc:1743
>  #2 0x00d04387 in cgraph_node::remove (this=   0x76dedaa0 "__ct_base "/18>) at ../../gcc/gcc/cgraph.cc:1884
>  #3 0x010da74f in symbol_table::remove_unreachable_nodes
>   (this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
>   ../../gcc/gcc/ipa.cc:518
>  #4 0x02b51e53 in ipa_inline () at
>   ../../gcc/gcc/ipa-inline.cc:2761
>  #5 0x02b52cf7 in (anonymous
>   namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
>   ../../gcc/gcc/ipa-inline.cc:3153
>  (etc)
>
> ... I presume that my assumption that cgraph_node::remove () should
> remove nodes from the cgraph_node::next chain is wrong?

Ummm the function does that through the call to
symtab_node::unregister.  But how is that related?

>
>>>
>>> And as a side question, do all clone nodes have a ->clones pointing to
>>> the same list of all clones, or are they in a tree-ish arrangement,
>>> where clones of clones end up forming a tree, with the clone_of pointer
>>> being a pointer to the parent?
>>
>> The latter, they form a tree.
>
> I see, that makes sense.  Thanks.
>
>>> (in this instance, the node that trips
>>> the assert has a nullptr clone_of and clones value, which would AIUI
>>> imply that it is the original)
>>
>> Yes.
>>
>>> This train of thinking doesn't end up involving any devirtualization
>>> code, which the PR was originally reproduced with, but my current theory
>>> is that devirtualizing here just exposed an edge case that is decently
>>> well hidden, rather than it playing a crucial role.
>>
>> The inlined function is - I believe erroneously - marked as reachable by
>> walk_polymorphic_call_targets() within the unreachable analysis - so
>> devirtualizing is somewhat crucial.
>>
>> I bel

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

[Jan Hubicka via Gcc]

Hi,
> 
> It seems to me that the most correct fix is to add to
> walk_polymorphic_call_targets a check that the obtained possible target
> is still referenced_from_vtable_p() - because the alias that was
> originally a virtual function is referenced from a vtable that at this
> point is also known to be gone.  But the check looks like it is possibly
> expensive, so I wanted to discuss this with Honza first (hopefully next
> week).

External vtables are bit special since they can refer to things that are
not accessible in current unit (static functions from other translation
units etc).
We already have and test can_refer_decl_in_current_unit_p but we test it
before alias resolution (which is there just to avoid artifically
bumping up the number of possible targets)

So perhaps following untested patch would work?

diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 14cf132c767..b33ec708d47 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -2420,7 +2420,8 @@ maybe_record_node (vec  &nodes,
   alias_target = target_node->ultimate_alias_target (&avail);
   if (target_node != alias_target
  && avail >= AVAIL_AVAILABLE
- && target_node->get_availability ())
+ && target_node->get_availability ()
+ && can_refer_decl_in_current_unit_p (target_node->decl, NULL))
target_node = alias_target;
 }
 
I am at conference and will be able to test it only during weekend.
Honza
> 
> >
> > I had already figured that an error could've likely been in
> > reach-ability analysis, but my time ran low, and I had not confirmed
> > anything, or as little as formalized a theory, so I just wrote the
> > original email instead of following this trail of thought fully.
> >
> > Thank you for your guidance!  Have a lovely night :)
> 
> It is good thing that you asked, I also learned something new (that
> virtual and non-virtual functions can be ICFed together).
> 
> Martin

The macro STACK_BOUNDARY may overflow

[Paul Iannetta via Gcc]

Hi,

Currently, the macro STACK_BOUNDARY is defined as

  Macro: STACK_BOUNDARY
 Define this macro to the minimum alignment enforced by hardware for
 the stack pointer on this machine.  The definition is a C
 expression for the desired alignment (measured in bits).  This
 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not
 defined.  On most machines, this should be the same as
 'PARM_BOUNDARY'.

with no mentions about its type and bounds.  However, at some point, the value
of this macro gets assigned to the field "regno_pointer_align" of "struct
emit_status" which points to an "unsigned char", hence if STACK_BOUNDARY gets
bigger than 255, it will overflow...  Thankfully, the backend which defines the
highest value is microblaze with 128 < 255.

The assignment happens in "emit-rtl.c" through the REGNO_POINTER_ALIGN macro:

in function.h:
  #define REGNO_POINTER_ALIGN(REGNO) (crtl->emit.regno_pointer_align[REGNO])
in emit-rtl.cc:
  REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = STACK_BOUNDARY;
  [...]
  REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY;

Would it be possible to, either add an explicit bound to STACK_BOUNDARY in the
manual, and/or use an "unsigned int *" rather than and "unsigned char *" for
the field "regno_pointer_align".

Thanks,
Paul

gcc-11-20230324 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 2055702e8d492be6e978fa93a7bfefd358d5d9e3

You'll find:

 gcc-11-20230324.tar.xz   Complete GCC

  SHA256=1a4fb184a8257e2d414e4646768b0133bc6a6e76185e38822b42b4f4dc30bad6
  SHA1=c045085ab914199e56f6218fd4ae7abb7135bad6

Diffs from 11-20230317 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
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.

Building gcc-12 on MacOS Ventura (aarch64)

[Chris Johns]

Hi,

I am sorting out some issues building RTEMS on MacOS including the M processors.
The building gcc-12.2.1 for the few architectures I tested fail with sig faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a result I
wondered about bootstrapping gcc and using that to build the tools rather than
clang from Xcode.

Is aarch64-apple-darwin supported? I am seeing:

*** Configuration aarch64-apple-darwin22.3.0 not supported

Thanks
Chris

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023, 23:03 Chris Johns,  wrote:

> Hi,
>
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
> result I
> wondered about bootstrapping gcc and using that to build the tools rather
> than
> clang from Xcode.
>
> Is aarch64-apple-darwin supported?



No. Iain Sandoe has some personal branches with changes to support it, but
the changes are not in the official gcc repo yet. If you search the
gcc-h...@gcc.gnu.org list you'll find links to his code. I think Homebrew
is his patches too.


I am seeing:
>
> *** Configuration aarch64-apple-darwin22.3.0 not supported
>
> Thanks
> Chris
>

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023, 23:07 Jonathan Wakely,  wrote:

>
>
> On Fri, 24 Mar 2023, 23:03 Chris Johns,  wrote:
>
>> Hi,
>>
>> I am sorting out some issues building RTEMS on MacOS including the M
>> processors.
>> The building gcc-12.2.1 for the few architectures I tested fail with sig
>> faults
>> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
>> result I
>> wondered about bootstrapping gcc and using that to build the tools rather
>> than
>> clang from Xcode.
>>
>> Is aarch64-apple-darwin supported?
>
>
>
> No. Iain Sandoe has some personal branches with changes to support it, but
> the changes are not in the official gcc repo yet. If you search the
> gcc-h...@gcc.gnu.org list you'll find links to his code. I think Homebrew
> is his patches too.
>

*uses his patches too.


>
> I am seeing:
>>
>> *** Configuration aarch64-apple-darwin22.3.0 not supported
>>
>> Thanks
>> Chris
>>
>

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Chris Johns]

On 25/3/2023 10:07 am, Jonathan Wakely wrote:
> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely,  > wrote:
> On Fri, 24 Mar 2023, 23:03 Chris Johns,  > wrote:
> 
> Hi,
> 
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with 
> sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As 
> a
> result I
> wondered about bootstrapping gcc and using that to build the tools
> rather than
> clang from Xcode.
> 
> Is aarch64-apple-darwin supported?
> 
> No. Iain Sandoe has some personal branches with changes to support it, but
> the changes are not in the official gcc repo yet. If you search the
> gcc-h...@gcc.gnu.org  list you'll find links 
> to
> his code. I think Homebrew is his patches too.
> 
> *uses his patches too.
> 

I tried Iain's repo and it fails in the same way.

I have been building the tools on MacOS for over a decade with just the Apple
base to make sure we have a clean platform without any issues. To do that I
avoid MacPorts and Homebrew. I am fine with our users making use of those
packages however knowing a build works with just the Apple support makes our
support simpler.

Chris

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Stuff Received]

On 2023-03-24 19:51, Chris Johns wrote:

On 25/3/2023 10:07 am, Jonathan Wakely wrote:

On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, mailto:jwakely@gmail.com>> wrote:
 On Fri, 24 Mar 2023, 23:03 Chris Johns, mailto:ch...@contemporary.net.au>> wrote:

 Hi,

 I am sorting out some issues building RTEMS on MacOS including the M
 processors.
 The building gcc-12.2.1 for the few architectures I tested fail with 
sig
 faults
 in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
 result I
 wondered about bootstrapping gcc and using that to build the tools
 rather than
 clang from Xcode.

 Is aarch64-apple-darwin supported?

 No. Iain Sandoe has some personal branches with changes to support it, but
 the changes are not in the official gcc repo yet. If you search the
 gcc-h...@gcc.gnu.org  list you'll find links 
to
 his code. I think Homebrew is his patches too.

*uses his patches too.



I tried Iain's repo and it fails in the same way.

I have been building the tools on MacOS for over a decade with just the Apple
base to make sure we have a clean platform without any issues. To do that I
avoid MacPorts and Homebrew. I am fine with our users making use of those
packages however knowing a build works with just the Apple support makes our
support simpler.

Chris


I am able to build gcc from Iain's repo gcc-darwin-arm64 on an M1 Mini, 
running macos 11.3.1, using the following configuration.  (Change your 
language preferences accordingly.)  I used make -j4.


CC=/opt/homebrew/bin/gcc-12 \
CXX=/opt/homebrew/bin/g++-12 \
../../src/gcc-darwin-arm64/configure \
--prefix=$HOME/gm2/arm64 \
--exec-prefix=$HOME/gm2/arm64 \
--enable-languages=c,c++,m2 \
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \
--with-mpc=/opt/homebrew \
--with-gmp=/opt/homebrew \
--with-mpfr=/opt/homebrew \
--disable-bootstrap \
--enable-threads=posix

However, you must first define HAVE_FCNTL_H to 1 in libiberty/config.h 
(that is missed somehow by configure).


Sincerely,
N.