portable way to modify the FP register?

Hi,

I'd like to know if there's a portable way of modifying the FP register, in LLVM.

Suppose foo() calls bar(); bar emits a result but remains active and needs to be able to produce more results - a bit like a coroutine. We want bar to restore FP to what it was inside foo before transferring control back to foo (bar's stack frame is not disposed of).

We'd make sure that foo only accesses local variables via FP (SP addressing is disabled).

What we'd like to do is something like (abstracted syntax and semantics :slight_smile:
  (FP) = @llvm.frameaddress(1) ;

So, is there a portable way to change FP?

So, is there a portable way to change FP?

What if there is no FP register on a given target?

Hi,

To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set?

Also, I'm intrigued as to how you guarantee that in the intervening time between the coroutine/generator function bar() returning one result and the next invocation of bar(), foo() doesn't call another function and overwrite bar()'s stack frame?

Cheers,

James Molloy
Graduate Compiler Engineer, ARM Ltd.

Hi again,

To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set?

for the moment we're only considering X86-64 targets and we're forcing the FP to be materialized (ie, -disable-fp-elim) to ensure we can be independent of what happens to SP.

btw, I can't think of any current ISA/ABI which doesn't have a frame pointer register...

Also, I'm intrigued as to how you guarantee that in the intervening time between the coroutine/generator function bar() returning one result and the next invocation of bar(), foo() doesn't call another function and overwrite bar()'s stack frame?

the stack frame allocated by bar (called by foo) did not get released, and foo needs to use fp-based addressing. bar's stack frame now occupies the top of the stack and this will be in effect when the subsequent functions get called, which will create new stack frames on top of bar's.

we're defining a new calling convention which expects certain calls' frames to linger (similar to coroutining)

cheers,
Salvador

Hi again,

To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set?

for the moment we're only considering X86-64 targets and we're forcing the FP to be materialized (ie, -disable-fp-elim) to ensure we can be independent of what happens to SP.

How does this ensure independence from the stack pointer? It seems
like the code generator is still free to generate references from the
SP base if it chooses to, unless you're hacking it up or have other
plans.

btw, I can't think of any current ISA/ABI which doesn't have a frame pointer register...

Also, I'm intrigued as to how you guarantee that in the intervening time between the coroutine/generator function bar() returning one result and the next invocation of bar(), foo() doesn't call another function and overwrite bar()'s stack frame?

the stack frame allocated by bar (called by foo) did not get released, and foo needs to use fp-based addressing. bar's stack frame now occupies the top of the stack and this will be in effect when the subsequent functions get called, which will create new stack frames on top of bar's.

we're defining a new calling convention which expects certain calls' frames to linger (similar to coroutining)

It seems like it would be easier to insert shims around calls into and
out of the coroutine to switch from the stack to your coroutine's
frame, and then when calling out, switch back to the regular stack.
But perhaps your plan is to leave the SP alone for efficiency, and
just do all frame references through the base pointer.

I don't think there is any such intrinsic. I think you'll have to
write up some assembly yourself, which should be easy, or you could
create such an intrinsic. The harder trick will be convincing the
backends to leave the stack pointer alone.

Reid

Hi,

That seems sensible, but:

for the moment we're only considering X86-64 targets and we're forcing
the FP to be materialized (ie, -disable-fp-elim) to ensure we can be
independent of what happens to SP.

Does it therefore seem surprising that there is no way to do this portably? :wink:

James Molloy
Graduate Compiler Engineer, ARM Ltd.