On Wed, Feb 13, 2013 at 12:07:52PM -0600, Aldy Hernandez wrote:
> >Sorry, just noticed:
> >
> >>+ /* If the optabs changed, record it in the node. */
> >>+ if (memcmp (tmp_target_optabs, &default_target_optabs,
> >>+ sizeof (struct target_optabs)))
> >
> >This should be this_target_optabs rather than &default_target_optabs.
> >Nothing but target code and initialisers should use &default_target_optabs
> >directly.
>
> Fixed.
>
> >
> >I don't think that needs a retest though. It only makes a difference
> >on MIPS.
>
> I verified that the testcase is still fixed by this patch (just in
> case). Thanks so much for the review.
>
> Final patch attached.
Actually, thinking more about SWITCHABLE_TARGETS, I don't think this works
at all on those targets. this_target_optab is some random optab from
whatever has been left there by previous function, it can be either the
same, or different target (mips vs. mips16?). So, for SWITCHABLE_TARGETS,
I'm afraid you really can't save the optabs in the optimization node
(because, there could be different optabs for say all of
-Ofast + mips, -Ofast + mips16, -O2 + mips and -O2 + mips16 combinations),
but you probably can't save it even from within the target hook, because
some non-default optimization node might be in effect.
So, for SWITCHABLE_TARGETS, I think you can only save it in
cfun->this_fn_optab or similar, and perhaps cache the default for mips16
only when you know the default optimization node is in effect (or force it
into effect temporarily).
For !SWITCHABLE_TARGETS, you can easily remember it in the optimization
nodes and just copy the pointer over to cfun->this_fn_optab.
And unfortunately it seems optimize attribute is supported everywhere, just
the target attribute is not.
But, as soon as it is reachable from cfun->this_fn_optab, we might need to
GC allocate it, while optimization nodes are never freed, cfun is freed I
think.
Jakub
