A plan to remove CUMULATIVE_ARGS [was: Re: RFA: PR44566: accessor macros (1/3): CUMULATIVE_ARGS]

[Joern Rennecke]

Quoting Nathan Froyd <froydnj@codesourcery.com>:

> I do not understand the relevance of this comment.  I agree that
> CUMULATIVE_ARGS is a target dependent type.  The plan that I posted is
> about removing the exposure of CUMULATIVE_ARGS to the non-backend
> portions of the compiler.

The problem is that when CUMULATIVE_ARGS becomes (more entrenched as)
part of the target hook interface, you'll have some 40 places for each
hook in the config files that need to be fixed to remove that
target-dependence from the target vector again.  That's a lot more work
than doing anything to the call site.

>  The above step is one step along the way.  A
> later step converts this returning of 'CUMULATIVE_ARGS *' to 'struct
> cumulative_args *'; a forward declaration of 'struct cumulative_args'
> can be provided in an appropriate header file.  If people are happier
> with 'void *', that's fine too.  I was aiming for slightly
> self-documenting code.

You can use a define or typedef to make that void * more self-documenting.
In fact I was thinking the other day that that's what I should do with
the enum reg_class -> int conversion too.
That should also make it easier if we later find a better way of doing
thing by some clever use of classes, or for register classes, if we get
to use any new language feature that allows to have an int for the interface
but treat it as passing / receiving an enum for type check purposes.

So if you do a
#define CUMULATIVE_ARGS_U CUMULATIVE_ARGS
and then use that in the target hook interface, and in the target hooks,
and cast between CUMULATIVE_ARGS_U * and CUMULATIVE_ARGS * as appropriate,
only the define would need to be changed to remove the target-dependency
from the target vector.

> I think that a multi-threaded gcc is a *long* way off.

I don't think it needs to be that far off.  So far, there was little demand
for it, because make -j works so well.  That will no longer be that case
with lto.  At the same time, we see the number of cores and available
simultaneously executed threads in workstation / server class machines
rising.  We might not want to care about all the details of handling
multithreading, but being able to apply some OMP directives to leverage
GOMP might already give some nice speedups, plus it's a matter of eating
our own dog food, so to speak.

> If we did ever
> get to that point, one thread-specific variable and the cost of its
> accesses would be the least of our problems.

I think it is important to keep future requirements in mind when we have
some choice when doing a design decision.  At the moment the cost of selecting
different paths is low; it's going to be much more expensive to switch later.

It's not the number of variables that matters so much as the number of
variable accesses during a compilation.  For typical C code (as compilation
workload for gcc) CUMULATIVE_ARGS accesses are probably not that important,
as we don't process function calls that often.  For C++ with lots of small
member functions I would expect that to be a little more.

But more importantly, once a particular way of doing things is established
in one place in GCC, it has a tendency to spread to other places where
analogous problems are encountered.