Re: RFA: Fix other/44566

[Joern Rennecke <amylaar at spamcop dot net>]

Quoting Mark Mitchell <mark@codesourcery.com>:
> All the work people are doing to help turn things into hooks, and such,
> is of course a step in the right direction; part of what we need for
> this is to avoid having target macros affecting the front- and
> middle-end compiler components.

As my work shows, having the hooks coded in the individual targets is not
required - using the existing macros to provide hooks works just fine.
Moreover, a rush to convert target macros into hooks with ill-conceived
parameters that become part of the interface for target ports actually
makes it harder to make a multi-target compiler, because then you actually
have to fix the parameters for every target that implements the hook.

Instead, what we should strive for is to use the existing macros to define
hooks in a few smallish files, to isolate the bulk of the code from target
dependencies.
If some code will run significantly slower if it has to use hooks instead of
macros, leaving it as target-dependent is also a viable choice, if we can
separate it properly from the target-independent code.  E.g. if we find that
the register allocator works better riddled with target macros,
than compiling it once per target is OK.

Simple macros like FIRST_PSEUDO_REGISTER can make it much easier for the
build compiler to optimize rtl passes and the utility functions they use
(e.g. unrolling works better with constants), so in the absence of
evidence to the contrary, I would suspect every rtl pass to suffer
performance degradation if it was fully hookized.

And rtl is always target-dependent anyway, so if we want compile flow to
diverge to go to different targets, it is natural to put this point at the
tree->rtl conversion.