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]

Re: SPARC, register renaming, __builtin_return_address

At 18:15 14.05.2001, Mark Mitchell wrote:
> >>>>> "David" == David Edelsohn <> writes:
>     David>      I think this is the key point: either return 0 for
>     David> b_r_a(1) or force a stack-frame when b_r_a() is detected.
>We can't control the caller.  To do b_r_a (N) we have to make
>assumptions about the the call frames up the stack.  I think we can
>assume whatever the psABI requires on the platform, which is usually
>enough to do the unwinding.
>But, I'm not sure what "force a stack frame" means.

On PPC the return address lives in a register until you have a non-leaf 
function, at that point it will be stored in the callers frame during the 
function prologue. Now, for walking back the stack chain starting from a 
leaf function it is easiest to force creation of a stack frame if we detect 
b_r_a(n>=1) in that function, see rs6000.c:rs6000_return_addr.

Damned, I just realize you were _solely_ talking about -O3 here (I somehow 
got the impression you were talking about -O2 and higher). Now, that _is_ 
different and we can't currently make any promises with inlined functions 
containing b_r_a. I already try to prevent inlining in the testcase (use of 
alloca, cause we don't have __attribute__((noinline))), I dunno why this 
doesn't work on SPARC. Hmm, maybe we can clear DECL_INLINE for a function 
if it contains b_r_a? Or set cfun->cannot_inline, though maybe that's too 
late now with tree-based inlining?

Hmm, now why didn't I think of that when I did the testcase? Does anything 
above sound reasonable?


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