Re: Can we speed up the gcc_target structure?

[Ian Lance Taylor <ian@wasabisystems.com>]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Any change along these lines loses what I think is a critical property
> of the target vector, which is that modifications to the target-specific
> code on the far side of it do *not* require recompilation of the
> entire machine-independent compiler.
> 
> I consider it a desirable and achievable goal to be able to swap out
> the entire back end without rebuilding any of the optimizers; this
> entails having *everything* go through the target vector or some other
> sort of link-time interface.  (For instance, I see no need to change
> the way recog.c interacts with insn-recog.c for this purpose.)
> 
> Furthermore, while a 3% measured speed hit is a concern, I think that
> trying to win it back by undoing the targetm transformation - in the
> object files, if not in the source code - is barking up the wrong
> tree.  Instead we should be looking for ways to avoid having targetm
> hooks in critical paths in the first place.  It's been my experience
> that that is a much more fruitful source of optimization
> opportunities.

I don't have anything against that goal, but it is in conflict with
the goal of speeding up the compiler.  Simply moving targetm hooks
obviously can not get you the full speedup.  The full speedup comes
when an optimizing compiler compiling gcc can see that certain values
are constants, such as, in my example, the various promote_* functions
in the target vector.  You can't pull those target hooks out of the
critical path.  Function calls are on the critical path for a
non-optimizing compilation of many types of C++ code, and a
non-optimizing compilation is the case where compilation speed is the
most important.

At best you can replace target hook function calls with target hook
memory references.  For example, you could somehow detect that
promote_function_args always returns false for the i386.  I'm not sure
how to do that cleanly, without adding a dependency between target
hooks which would be a source of future bugs, but it may be possible.
But even a memory reference is going to be slower than a compile-time
constant.

Also, as more and more control moves into the target vector, which I
think we all agree is a good goal, it will slow down the compiler more
and more.

As I say, your goal is a good one.  And it may trump the goal of
maximizing compiler speed.  Although I will note that your goal
benefits only compiler developers.  And maximizing compiler speed
benefits compiler users.  And obviously we could have a configure
option which forced all calls to go through the target vector, as I
discussed in my original message--that configure option could then
affect the Makefile dependencies.  That would make it easier for
developers, at the cost of possibly introducing unnoticed bugs.

Ian