This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix SPEC slowdown from function specific branch


On Fri, Aug 08, 2008 at 05:11:05PM +0200, Michael Matz wrote:
> Hi,
> 
> On Fri, 8 Aug 2008, H.J. Lu wrote:
> 
> > > initially but it's certainly the wrong place.  This fixes the severe 
> > > SPEC regression from r138154 .
> > 
> > optimization_options may be called by function specific optimization, 
> > which may turn off TARGET_SCHEDULE for specific functions.
> 
> I sure hope not.  That flag can only be (re)set via tuning options, i.e. 
> using a different -mtune=xyz option.  I hope you aren't saying that this 
> is possible with function specific attributes because in that case it 
> would be broken right now (as it doesn't call override_options anywhere).

Function specific options can change the arch/tune support.  And
override_options is called each time the attribute/#pragma is used via
ix86_valid_option_attribute_tree.

> > Your patch will break it.  I think the proper fix is to make sure that 
> > we should check if override_options has been called before checking 
> > TARGET_SCHEDULE blindly in optimization_options.
> 
> We still would need the same hunk in override_options, though, in case the 
> user is not using function specific attributes.  Code duplication -> bad.
> The whole handling of the difference between override_options and 
> optimization_options (at least for the x86 backend) of the function 
> specific infrastructure looks a bit dubious to me.  optimization_options 
> on the x86 backend does nearly nothing, while most things are decided in 
> override_options.  Still the former is used by the function specific 
> callbacks but the latter isn't.

Well the later is used if you change the optimization options via the optimize
attribute/#pragma.

> I wasn't able to really disentangle this, though, but did notice that the 
> patch I sent couldn't break anything which wouldn't be broken right now 
> anyway, so ...

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]