<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 08/26/2015 07:02 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KipUBD3WYPJFmE5HOyE6KuGcJU0RMD=cbJyEfk_w-_yjg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar
via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div>
<p class="MsoNormal">Currently, the <span
style="font-size:10.0pt;font-family:Consolas">
alloca</span> instruction always allocates in the
generic address space (0).</p>
<p class="MsoNormal">This proposal is to extend the
semantics of <span
style="font-size:10.0pt;font-family:Consolas">
alloca</span> instruction to allow allocation in any
specified address space.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>Proposed Syntax</b></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:Consolas"><result>
= alloca [inalloca] <type> [, <ty>
<NumElements>] [, align <alignment>]
<b>[, <span style="color:black;background:white">addrspace
</span><<span
style="color:black;background:white">num</span>>]</b>
; yields type addrspace(num)*:result</span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:Consolas"> </span></p>
<p class="MsoNormal"><b>Motivation</b></p>
<p class="MsoNormal">Managed language clients typically
use address space 1 to represent GC-pointers.</p>
<p class="MsoNormal">Some managed clients (CLR, in
particular) allow construction of GC pointers to stack
locations.</p>
<p class="MsoNormal">For example, MSIL instruction
ldloca (ECMA 335, p 370) creates a GC pointer to a
stack local.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Creating an <span
style="font-size:10.0pt;font-family:Consolas">
addrespace(1)*</span> pointer to a stack location
currently involves two steps: the
<span style="font-size:10.0pt;font-family:Consolas">alloca</span>,
and an <span
style="font-size:10.0pt;font-family:Consolas">
addrspacecast</span>.</p>
<p class="MsoNormal">Managed code transformations (ex: <span
style="font-size:10.0pt;font-family:Consolas">
RewriteStatepointsForGC</span>) do not handle
arbitrary address space casting.</p>
<p class="MsoNormal">So, it is desirable to obtain the <span
style="font-size:10.0pt;font-family:Consolas">
addrespace(1)*</span> pointer by construction.</p>
</div>
</div>
</blockquote>
<div>I don't have a particular or specific objection here
necessarily, but I have to admit I don't understand the use
case (yet). I'm hoping you can explain it to me more
thoroughly.</div>
<div><br>
</div>
<div>What semantics do you expect for GC pointer to a stack
location? That's what I don't really understand. Some
questions that leap to mind, but may be the wrong questions
(so feel free to point me in the right direction here)...</div>
<div><br>
</div>
<div>- Can I promote such a location to an SSA register?</div>
<div>- What does it mean to collect a stack location?</div>
<div>- Can I merge stack allocations that are GC pointers? Can
I re-use them? What semantics do I get?</div>
<div>- Do GC pointers to stack locations have any different
aliasing properties?</div>
<div>- When the optimizer needs to create a new stack
allocation, what address space should it be in?</div>
</div>
</div>
</blockquote>
For the proposed solution, what I think Swaroop is going for is
simply having a mechanism to distinguish some allocas from others
without otherwise effecting code generation. They are still stack
based objects; they don't escape unless unused at a safepoint;
they're not relocated. They may contain pointers to objects which
do need to be relocated, so we need to have a mechanism to track
them. In particular, it would be perfectly legal to promote to SSA
since the interior pointers would become addrspace(1) SSA values and
be handled correctly by the relocation logic.<br>
<br>
I can't answer the merging question above. There are entirely sane
semantics which could be assigned to stack allocation merging, but
I'm not sure what expectations the CLR GCs have. <br>
<br>
Swaroop - If I've misstated anything above, please correct me. <br>
<br>
<blockquote
cite="mid:CAGCO0KipUBD3WYPJFmE5HOyE6KuGcJU0RMD=cbJyEfk_w-_yjg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Ultimately, to make this change, you'll also need to
change a decent amount of code in the optimizer that will
blindly create stack allocations in address space zero.</div>
<div><br>
</div>
<div>Without a better understanding of both the motivation and
the resulting consequences such as what I've outlined in my
questions above, it is very hard for me to feel comfortable
with this kind of change.</div>
</div>
</div>
</blockquote>
This is basically my reaction as well. This seems like a big hammer
to a problem I'm not sure is actually a nail. <br>
<blockquote
cite="mid:CAGCO0KipUBD3WYPJFmE5HOyE6KuGcJU0RMD=cbJyEfk_w-_yjg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal">Swaroop.</p>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>