This is the mail archive of the
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: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20161207121400.GM2767@gate.crashing.org> <firstname.lastname@example.org> <20161207124232.GN2767@gate.crashing.org> <alpine.LNX.email@example.com>
- 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.