[LLVMdev] Position-independent stacks
Vadim
vadimcn at gmail.com
Fri Jan 24 12:54:04 PST 2014
On Thu, Jan 23, 2014 at 7:13 PM, Mark Seaborn <mseaborn at chromium.org> wrote:
> 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:
>
<snip>
> 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.
>
I think I can hoist all those variables into the heap-allocated frame as
well. The same for returning structs. In this case it's actually very
fortunate that it's the front end that has to deal with the platform ABI,
otherwise I'd have to guess which return values backend code generator is
going to re-write as returns into the caller allocated buffer. (Or are
there platforms which do that in the backend???)
> 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?
>
Synchronous only.
thanks!
Vadim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140124/bf607511/attachment.html>
More information about the llvm-dev
mailing list