This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can shrink-wrapping ever move prologue past an ASM statement?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>, Vojtech Pavlik <vojtech at suse dot cz>, Josh Poimboeuf <jpoimboe at redhat dot com>
- Date: Wed, 8 Jul 2015 05:36:31 -0500
- Subject: Re: Can shrink-wrapping ever move prologue past an ASM statement?
- Authentication-results: sourceware.org; auth=none
- References: <20150707175349 dot GA2325 at virgil dot suse dot cz> <20150707184415 dot GB13004 at gate dot crashing dot org> <20150708092309 dot GB2325 at virgil dot suse dot cz>
On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
> > For other archs, e.g. x86-64, you can do
> >
> > register void *sp asm("%sp");
> > asm volatile("call func" : "+r"(sp));
<snip>
> Well, I only have had a quick look at where things "go wrong" and have
> not spent much time thinking about all the things that coud break by
> moving an asm statement before stack frame setup so I don't know.
What goes wrong is that the "plain" asm (just the call) does not say it
needs the prologue of this function to be before it. But it needs some
of its effects: at least it needs the stack pointer changes (by the
prologue) to be done before it.
Writing the asm with a clobber of the stack pointer causes all stack
accesses to go via the frame pointer, which causes pretty horrible
code.
Using just an input of the stack pointer, like in
register void *sp asm("%sp");
asm volatile("call func" : : "r"(sp));
also works, at least in my simple test case; but the version that also
writes to sp prevents the asm's movement more.
> Nevertheless, given that this was discovered only now, it might not be
> a common problem but of course it may become one if we improve
> shrink-wrapping further.
GCC 5 and/or GCC 6 make shrink wrapping more aggressive, quite nice.
> Using a register variable seems like a workaround,
That is only a workaround for the fact that there is no other way to
say "this input should be in this specific register" (in general;
some ports have such constraints for some registers).
Having the asm take the stack pointer as input is hackish yes.
> so having a "stack" input operand is probably worth some
> further thought.
It would be nice if you could just say "this asm has to stay behind
the prologue", yes. I suggested using a special clobber, not an input,
but that is just syntax quibbles.
The question is if this usage is common enough to warrant a special
syntax at all.
Segher