<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 January 2014 15:23, Vadim <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Thanks Mark!  That'd be a useful starting point.<br></div><div><br>For the rest of the people here: to be a bit more specific, I am having doubts about the following:<br></div>
<div>
</div>- 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?<br>
</div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Otherwise, for code generation, I can think of one case where you will get a non-relocatable stack:  by-value argument passing.  For example:</div><div><br></div><div>void receive_struct(struct foo x) {</div>
<div>  receive_ptr(&x);</div><div>}</div><div><br></div><div>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].</div>
<div><br></div><div>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:</div>
<div><br></div><div>void receive_struct(struct foo x) {</div><div>  // The alloca for x_copy should be expanded out later by ExpandAlloca,</div><div>  // so that it will point into the non-relocatable stack.</div><div>  struct foo x_copy = x;</div>
<div>  // &x may be stored onto the relocatable stack and may become invalid,<br></div><div>  // but that's OK because we don't use it further.</div><div>  receive_ptr(&x_copy);</div><div>}</div><div><br></div>
<div>However, I don't think you can make that work for returning structs by value.</div><div><br></div><div>Varargs has a similar problem to passing structs by value.</div><div><br></div><div>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?</div>
<div><br></div><div>Cheers,</div><div>Mark</div><div><br></div><div>[1] <a href="https://chromium.googlesource.com/native_client/pnacl-llvm/+/7f634ce6f622188cd551dbf283131b03d019583d/lib/Transforms/NaCl/ExpandByVal.cpp">https://chromium.googlesource.com/native_client/pnacl-llvm/+/7f634ce6f622188cd551dbf283131b03d019583d/lib/Transforms/NaCl/ExpandByVal.cpp</a></div>
<div><br></div></div></div></div>