On Thu, Jan 09, 2014 at 12:11:12PM +0100, Richard Biener wrote:
> On Thu, Jan 9, 2014 at 11:24 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Thu, Jan 09, 2014 at 09:02:28AM +0000, Richard Sandiford wrote:
> >> It looks like a correct fix, but the memcpy is going to be pretty
> >> expensive, since in most cases there will be no difference.
> >
> > Perhaps we should add another tree code, which would represent the
> > combination of TARGET_OPTION_NODE and OPTIMIZATION_NODE, FUNCTION_DECL
> > would then refer to this combo node only and that new tree would
> > refer to both TARGET_OPTION_NODE and OPTIMIZATION_NODE.
> > That way we could stick the saved optabs into the new node rather than
> > having default opt cached target optabs, non-default opt with default
> > target optabs cached too, but for non-default target non-default opt we
> > don't cache anything and always recompute.
> >
> > Or perhaps just merge both TARGET_OPTION_NODE and OPTIMIZATION_NODE
> > into one and let both target and optimize attributes adjust it?
>
> Yeah - I fail to see why we have two different tree nodes here anyway.
Well, if the target_reinit stuff (except for optabs) is only dependent on
the target flags and not on the optimization flags (is that really the
case?), then by not having a single node only it is possible to save the
0.5MB or what target blob only once per target specific option combination,
while with only one node we'd need to duplicate that. And, I think
OPTIMIZATION_NODE works regardless of target support, doesn't need
target_reinit etc.
Jakub
