status of back end reinitialization patch

status of back end reinitialization patch

[Sandra Loosemore]

When I was retesting the back end reinitialization and mips16 function attribute 
patches after implementing changes from the last round of review (thanks 
Richard!), I ran into something that looks like a show-stopper problem, and I 
need to get some feedback about how to proceed.

The problem is that the existing patch hooks into tree_rest_of_compilation as 
the point at which to invoke the back end reinit function.  But this turns out 
to be too late.  The specific problem I ran into was an example where stuff in 
tree-vect-generic.c was deciding not to lower a V2HImode multiplication based on 
seeing backend support for it in the optab -- but then we reset the optab before 
doing the RTL generation, which became unhappy with being handed an operator it 
didn't know how to expand.

Since there are likely other middle-end transformations that rely on testing 
back end features, at the very least we need to put a hook in 
tree_lowering_passes as well.  More generally, it probably ought to be done 
whenever we set cfun.  We've been having some internal discussion about moving 
it into push/pop_cfun and auditing all other instances where cfun is currently 
being set directly to see if they can be rewritten to use stack discipline.  Or 
perhaps we can introduce some new primitives here.

Because this means that the back end mode-switching hook might be called many 
times per function, it starts to become more critical that it do some caching. 
The hook function we've implemented for the MIPS16 stuff checks to see whether 
we're already in the right mode, so at least the reinitialization cost will only 
happen when there really is a mode change, and be close to zero otherwise.  As I 
said the first time around with this patch, the "right" solution is really to 
wrap up the back end state into first-class objects that can just be swapped in 
and out, but that may not be practical at this point.

Anyway....  where does all this leave the current patch?  I've tidied up the 
current version; except for the problem noted above, it's testing quite cleanly 
on MIPS with -mflip-mips16.  I've decided to break it up into smaller pieces so 
that we can consider them individually.  One of the MIPS-specific cleanups (the 
part to kill the mips16_hard_float variable) has already been split out and 
committed separately.  I've split the non-MIPS-specific part into two pieces 
now; one to do the separation of the initialization actions into target-specific 
and non-target-specific pieces, and one to add the target hooks.  I know there's 
general resistance to committing half-implemented features, but if we're going 
to go ahead with this idea of supporting back end mode changes, then some 
variant of the initialization reorganization is going to have to be included 
anyway, so perhaps this could be considered on its own merits while we're still 
hashing out the details of where the right place for the hook is.  I'll repost 
the three remaining pieces (those two plus the remaining MIPS-specific part) 
here shortly.

Comments, thoughts, flames, etc?  I wasn't too sure about posting this on a 
Friday evening, but maybe anybody who's still reading their mail can think about 
it over the weekend.  ;-)

-Sandra