On Mon, May 24, 2021 at 10:56 AM Martin Liška <mli...@suse.cz> wrote:
>
> On 5/20/21 9:55 AM, Richard Biener wrote:
> > On Thu, May 20, 2021 at 12:29 AM Joern Wolfgang Rennecke
> > <joern.renne...@riscy-ip.com> wrote:
> >>
> >> We set default for some target options in TARGET_OPTION_OPTIMIZATION_TABLE,
> >> but these can be overridden by specifying the corresponding explicit
> >> -mXXX / -mno-XXX options.
> >> When a function bears the attribue
> >> __attribute__ ((optimize("02")))
> >> the target options are set to the default for that optimization level,
> >> which can be different from what was selected for the file as a whole.
> >> As handle_optimize_attribute is right now, it will thus clobber the
> >> target options, and with enable_checking it will then abort.
> >>
> >> The attached patch makes it save and restore the target options.
> >>
> >> Bootstrapped and regression tested on x86_64-pc-linux-gnu.
>
> Interesting, I prepared very similar patch for this stage1. My patch covers 
> few more
> cases where target options interfere with optimize options (and vice versa).
>
> >
> > That looks reasonable but of course it doesn't solve the issue that those
> > altered target options will not be in effect on the optimize("O2") function.
> >
> > IIRC Martin has changes in the works to unify target & optimize here
> > which should obsolete this fix.  Martin - what's the state of this?  Do you
> > think this patch makes sense in the mean time (and maybe also on
> > the branch though the assert is not in effect there but the behavior
> > is still observed and unexpected).
>
> Well, I really tried doing the merge but I failed. It's pretty huge task and 
> I was
> unable to get something reasonable for x86_64 target :/

I wonder what the big issue is - the point is that target and optimize options
should not vary independently and thus the caching should not happen
independently.  In the end this means unifying
DECL_FUNCTION_SPECIFIC_TARET/OPTIMIZATION or as a first step,
updating them always in lock-step.  Like making the existing macros
return an rvalue and providing set_* wrappers that perform a forceful
update of both with unified caching.

> However, my patch mitigates
> 2 more cases.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK - might be worth backporting to GCC 11?

Thanks,
Richard.

> Thanks,
> Martin
>
> >
> > Thanks,
> > Richard.
> >
>

Reply via email to