This is the mail archive of the
mailing list for the GCC project.
Re: Can shrink-wrapping ever move prologue past an ASM statement?
- From: Martin Jambor <mjambor at suse dot cz>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: 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 11:23:09 +0200
- 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>
On Tue, Jul 07, 2015 at 01:44:15PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote:
> > I've been asked to look into the item one of
> > http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
> > that at least shrink-wrapping happily moves prologue past an asm
> > statement which can be bad if the asm statement contains a call
> > instruction.
> > Am I right concluding that this is a bug? Looking into the manual and
> > at requires_stack_frame_p() in shrink-wrap.c, I do not see any obvious
> > way of marking the asm statement as requiring the stack frame (but I
> > will not mind being proven wrong). Do we want to create one, such as
> > only disallowing moving prologue past volatile asm statements? Any
> > other ideas?
> For architectures like PowerPC where all calls clobber some register,
> you can write e.g.
> asm("bl func" : : : "lr");
> and all is well (better than saving/restoring LR manually, too).
> For other archs, e.g. x86-64, you can do
> register void *sp asm("%sp");
> asm volatile("call func" : "+r"(sp));
Thanks, this is very clever and apparently what is going to be used:
> and the result seems to be optimal as well.
> Some special clobber, maybe "stack" (like "memory", which won't work)
> could be nicer? What should the *exact* semantics of that be?
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. I'm
CCing Josh who has been bitten by this, perhaps he can share some
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. Using a register variable seems like a
workaround, so having a "stack" input operand is probably worth some