This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]