This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to avoid constant propagation into functions?
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Georg-Johann Lay <avr at gjlay dot de>, Tim Prince <n8tm at aol dot com>, "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>, gcc at gcc dot gnu dot org
- Date: Wed, 7 Dec 2016 14:47:39 +0100
- Subject: Re: How to avoid constant propagation into functions?
- Authentication-results: sourceware.org; auth=none
- References: <nvi02s93wk5vagpi308y18xq.1480955596148@email.android.com> <2a24da63-8776-2f69-283a-cd11e63d7241@gjlay.de> <ab1d7722-ba83-5ddc-de7a-631e3ea971ee@gjlay.de> <20161207121400.GM2767@gate.crashing.org> <a9965b35-2dff-6d95-d95b-2f1720b53383@gjlay.de> <20161207124232.GN2767@gate.crashing.org> <alpine.LNX.2.20.13.1612071558360.19597@monopod.intra.ispras.ru>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Dec 07, 2016 at 04:12:48PM +0300, Alexander Monakov wrote:
> [adding gcc@ for the compiler-testsuite-related discussion, please drop either
> gcc@ or gcc-help@ from Cc: as appropriate in replies]
>
> On Wed, 7 Dec 2016, Segher Boessenkool wrote:
> > > For example, this might have impact on writing test for GCC:
> > >
> > > When I am writing a test with noinline + noclone then my
> > > expectation is that no such propagation happens, because
> > > otherwise a test might turn trivial...
> >
> > The usual ways to prevent that are to add some volatile, or an
> > asm("" : "+g"(some_var)); etc.
>
> No, that doesn't sound right. As far as I can tell from looking that the GCC
> testsuite, the prevailing way is actually the noinline+noclone combo, not the
> per-argument asms or volatiles.
>
> This behavior is new in gcc-7 due to new IPA-VRP functionality. So -fno-ipa-vrp
> gets the old behavior. I think from the testsuite perspective the situation got
> a bit worse due to this, as now in existing testcases stuff can get propagated
> where the testcase used noinline+noclone to suppress propagation. This means
> that some testcases may get weaker and no longer test what they were supposed
> to. And writing new testcases gets less convenient too.
>
> However, this actually demonstrates how the noinline+noclone was not
> future-proof, and in a way backfired now. Should there be, ideally, a single
> 'noipa' attribute encompassing noinline, noclone, -fno-ipa-vrp, -fno-ipa-ra and
> all future transforms using inter-procedural knowledge?
Or just disable IPA-VRP into functions with noclone attribute, consider
IPA-VRP as kind of virtual cloning.
Jakub