[LLVMdev] Position-independent stacks

[Mark Seaborn]

On 23 January 2014 15:23, Vadim <vadimcn at gmail.com> wrote:

> Thanks Mark!  That'd be a useful starting point.
>
> For the rest of the people here: to be a bit more specific, I am having
> doubts about the following:
>  - Can later optimization passes or code generation still create machine
> code that takes and stores (in a register perhaps) an address of something
> on the stack, even if not semantically visible to the programmer?   Can
> this somehow be detected?
>

If you are concerned about later optimisation IR passes, you should
probably ensure that you run something like ExpandAlloca as a last pass,
with no general-purpose IR passes afterwards.

Otherwise, for code generation, I can think of one case where you will get
a non-relocatable stack:  by-value argument passing.  For example:

void receive_struct(struct foo x) {
  receive_ptr(&x);
}

If you don't mind whether you keep the normal calling conventions of the
host architecture, you can lower and remove all of the "byval" IR
attributes.  The ExpandAlloca pass I referred to assumes this has already
been done by the ExpandByVal pass, which is one of PNaCl's IR
simplification passes [1].

Otherwise, it might be possible to do a more sophisticated version of
ExpandByVal that keeps "byval" but prevents a pointer into the stack from
being passed around.  e.g. For by-value arguments, the above would become:

void receive_struct(struct foo x) {
  // The alloca for x_copy should be expanded out later by ExpandAlloca,
  // so that it will point into the non-relocatable stack.
  struct foo x_copy = x;
  // &x may be stored onto the relocatable stack and may become invalid,
  // but that's OK because we don't use it further.
  receive_ptr(&x_copy);
}

However, I don't think you can make that work for returning structs by
value.

Varargs has a similar problem to passing structs by value.

Do you want to be able to relocate the stack only at function call
boundaries, or at any place that execution might be asynchronously
interrupted?

Cheers,
Mark

[1]
https://chromium.googlesource.com/native_client/pnacl-llvm/+/7f634ce6f622188cd551dbf283131b03d019583d/lib/Transforms/NaCl/ExpandByVal.cpp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140123/e3ad2088/attachment.html>