<div dir="ltr">Hello Tim,<div><br></div><div>Thanks for the reply. I am trying to write a compiler pass where I can assign a "type" to variables on the stack, heap and globals without modifying the form of the existing data. I assume the inalloca attribute works for return values as well?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 2, 2019 at 4:02 AM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Carter,<br>
<br>
On Fri, 1 Nov 2019 at 17:19, Carter Cheng via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I am curious if it is possible to get the actual address in memory of where the parameter or return memory location is on to the stack prior to the call or return being made in the LLVM IR.<br>
<br>
I suspect the answer depends on what you're hoping to do with that information.<br>
<br>
The "inalloca" attribute was added for a particular Windows use-case<br>
(where the ABI demanded the caller modify that memory in arbitrary<br>
ways before the call), and might be useful if you control the<br>
front-end or at least can insert a conversion pass without breaking an<br>
existing ABI you care about.<br>
<br>
Alternatively, the information is available at certain stages in the<br>
CodeGen. During call-lowering the offsets are assigned (as "some<br>
target-specific stack offset + N"); the targets generally know what<br>
that specific stack offset is and can go digging around if they want.<br>
<br>
So what do you plan to do with this information if you can obtain it?<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>