This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch][RFC] make lra.c:check_rtl set maybe_hot_insn_p
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Yvan Roux <yvan dot roux at linaro dot org>, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Richard Biener <richard dot guenther at gmail dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Vladimir Makarov <vmakarov at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Wed, 27 Nov 2013 19:20:49 +0100
- Subject: Re: [patch][RFC] make lra.c:check_rtl set maybe_hot_insn_p
- Authentication-results: sourceware.org; auth=none
- References: <52862E19 dot 7070403 at arm dot com> <CAD57uCcbuZaZNmozZ36+kgOqOS2EWjvsEX2qXrwjojeeB03raw at mail dot gmail dot com> <CAD57uCfUf4gxzc78P-UB8UHx8TwU5c1p2VGYhYpOPZFCA2jMyg at mail dot gmail dot com> <5289DA87 dot 1050601 at arm dot com> <528A3894 dot 6050500 at arm dot com> <CAD57uCfMMT-sChRKZ4xC0wG=4gCwMRRJ1VWKcH8n=CjUNe7B2g at mail dot gmail dot com> <CAD57uCd9pdvUCb1Xym_TvYJkkqBMH8Cfo6MpxmBZLaQHq0HHzQ at mail dot gmail dot com> <529629E4 dot 6070408 at redhat dot com> <CAD57uCdA=v4=8+8fCybrNP5Es5jpt0eztVYTqf6Pe2BP_tcQ1w at mail dot gmail dot com> <52963657 dot 6020804 at redhat dot com>
> On 11/27/13 10:30, Yvan Roux wrote:
> >>Please include either the patch you are pinging or at the least a link to it
> >>in the archives.
> >
> >Ok, sorry for that, here is the patch and Changelog
> >
> >Yvan
> >
> >
> >2013-11-17 Yvan Roux <yvan.roux@linaro.org>
> >
> > * config/arm/arm.md (store_minmaxsi): Use only when
> > optimize_function_for_size_p.
> Thanks.
>
> This is fine for the trunk. And yes, having an insn's validity
> change based on what block it's in is most definitely bad.
>
> I was a bit concerned have the x86 backend, as I happened to know it
> uses optimize_insn_for_* rather extensively. But thankfully it's
> only used in splitters, expanders & peephole2 patterns, which should
> all be safe.
Yep, this was (is) the plan - have instructions independent on profile (since
they can be freely moved from hot parts to cold and in weird cases also from
cold to hot) while expanders/splitters and peep2s may use profile to choose
appropriate generation strategy.
I tried to review backend for places where splitters/peeps/expanders are used
and set profile according reset it to default for the possible cases where
we call them from profile unaware pass.
Honza
>
> If you wouldn't mind, could you look at md.texi and see if there's a
> reasonable place to put verbage about this issue in the internals
> manual? It might save someone time in the future :-)
>
> Thanks,
> Jeff