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: Florian Weimer <fw at deneb dot enyo dot de>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, Georg-Johann Lay <avr at gjlay dot de>, Tim Prince <n8tm at aol dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 14 Dec 2016 18:27:46 +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> <87inqv4pk3.fsf@mid.deneb.enyo.de> <20161207174413.GP2767@gate.crashing.org>
* Segher Boessenkool:
> On Wed, Dec 07, 2016 at 06:27:56PM +0100, Florian Weimer wrote:
>> >> > 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.
>>
>> Agreed, that's what I've been using in the past for glibc test cases.
>>
>> If that doesn't work, we'll need something else. Separate compilation
>> of test cases just to thwart compiler optimizations is a significant
>> burden, and will stop working once we have LTO anyway.
>>
>> What about making the function definitions weak? Would that be more
>> reliable?
>
> It depends a lot on what you want the test to actually test.
The most recent case was about constructing the expected call stack
for an unwinder test.
In another test, I needed to perform free (malloc (1)).
> Just sprinkling noinline,noclone everywhere as a poor man's "DWIM"
> just does not work.
Maybe we should compile all glibc tests twice, once with
-ffreestanding, and once without, so that we test both the
implementation and what an application would do. But I don't know if
-ffreestanding would even work this way.