This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can shrink-wrapping ever move prologue past an ASM statement?


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
> > 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
further thought.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]