Re: Use predicates for RTL objects

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Aug 08, 2019 at 10:10:38AM +0100, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote:
> >> We already have, for eg, is_a <rtx_sequence *> (x), and there are
> >
> > Whis *is* a class.  And not all of us are happy with that, but since we
> > don't often have to see it at all, it's not so bad.
> 
> Speaking as someone who is happy about that[*]...
> 
> [*] ...at least in principle.  It isn't really a proper class yet
>     because we don't construct rtx sequences as rtx_sequence objects,
>     we just access them that way.  I was a bit surprised that this
>     was defined behaviour...

_In principle_, sure, I have nothing against C++ conversions if it has
advantages that outweigh their disadvantages.

> > If you really want to convert RTL to C++, you should start with getting
> > rid of rtx_format and rtx_class, and make REG_P etc. work just as they
> > have always done.
> 
> I don't think getting rid of rtx_format and rtx_class should
> necessarily be the first step.  The base class can still provide
> the traditional accessors (with runtime checking when enabled).

It is *the* core thing that needs to be changed if you want this to be
any other than pointless uglification.

Those two RTX fields are the core of how it works now.  If you want to
use C++ classes, instead, you need to replace them with some suitable
C++ thing.  And we need to see that design before we can say if it looks
acceptable at all.

> Another option would be to start adding derived classes for certain
> types of rtx, and actually constructing those types of rtx with the
> appropriate type.  It'd probably make sense to start with special-
> purposes rtxes like ADDRESS, DEBUG_IMPLICIT_PTR or SYMBOL_REF (which
> is already somewhat special).

I would prefer to see an overall design before making partial changes.

> IMO the advantages of using a proper class hierarchy would be:
> 
> - More static type checking.  Runtime RTL checking is still seen as too
>   expensive to enable by default even in development builds, so RTL goes
>   unchecked most of the time.

Many people enable it all the time.  It isn't so expensive compared to
other things.  --enable-checking=yes,rtl,tree saves more time than it
costs, ime, and "rtl" is not the most expensive in that.

> - More efficient layouts, rather than forcing every piece of information
>   outside the header to be in a pointer-sized field.

... and then the GC has to be tuned again.  Oh joy.  Well, it probably
is much detuned already, but :-)

It would be nice to see real numbers how much memory this would save, and
what that means for compiler runtime.


Segher