This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid constant propagation into functions?
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: 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 16:12:48 +0300 (MSK)
- 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>
[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?