This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid constant propagation into functions?
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: Jakub Jelinek <jakub at redhat dot com>, Alexander Monakov <amonakov at ispras dot ru>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, 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 15:39:30 +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> <20161207134739.GO3541@tucnak.redhat.com>
On 07.12.2016 14:47, Jakub Jelinek wrote:
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.
Are you saying that this is worth being reported as PR?