<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 03/16/2017 01:54 PM, Friedman, Eli
      via llvm-dev wrote:<br>
    </div>
    <blockquote
      cite="mid:689be6b4-a619-c04a-43f6-9fc4415c01e0@codeaurora.org"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">On 3/16/2017 10:51 AM, Arsenault,
        Matthew via llvm-dev wrote:<br>
      </div>
      <blockquote
cite="mid:CY1PR1201MB1003607AA399D6BFC0B5BE6AE2260@CY1PR1201MB1003.namprd12.prod.outlook.com"
        type="cite">
        <style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
        <div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
          color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
          <p>LLVM makes several assumptions about address space 0.
            However,</p>
          <p>alloca is presently constrained to always return this
            address space.</p>
          <p>There's no real way to avoid using alloca, so without this</p>
          <p>there is no way to opt out of these assumptions.</p>
          <p><span style="font-size:12pt"><br>
            </span></p>
          <p><span style="font-size:12pt">The problematic assumptions
              include:</span></p>
          <ul>
            <li><span style="font-size:12pt">That the pointer size used
                for the stack is the same size as </span><span
                style="font-size:12pt">the code size pointer, which is
                also the maximum sized pointer.</span></li>
            <li><span style="font-size:12pt">That 0 is an invalid,
                non-dereferencable pointer value.</span></li>
          </ul>
        </div>
      </blockquote>
      <blockquote
cite="mid:CY1PR1201MB1003607AA399D6BFC0B5BE6AE2260@CY1PR1201MB1003.namprd12.prod.outlook.com"
        type="cite">
        <div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
          color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
          <span style="font-size:12pt">These are problems for AMDGPU
            because alloca is used to </span><span
            style="font-size:12pt">implement the private address space,
            which uses a 32-bit </span><span style="font-size:12pt">index
            as the pointer value. Other pointers are 64-bit </span><span
            style="font-size:12pt">and behave more like LLVM's notion of
            generic address </span><span style="font-size:12pt">space.
            By changing the address space used for allocas, </span><span
            style="font-size:12pt">we can change our generic pointer
            type to be LLVM's generic </span><span
            style="font-size:12pt">pointer type which does have similar
            properties.</span>
          <div><br>
          </div>
          <div>The proposal here is to add a -A field to the datalayout
            string which will specify the address space for allocas.
            IRBuilder::CreateAlloca and company gain a DataLayout
            argument, and some intrinsics that currently don't support
            address spaces need to support them.</div>
          <div><br>
          </div>
        </div>
      </blockquote>
      <br>
      I think we should also include the address-space of each alloca
      explicitly in textual IR.  Having the type depend on the
      datalayout would be confusing, because you'd need to look at the
      datalayout to figure out which address-space the alloca in a
      snippet of IR uses.<br>
    </blockquote>
    <br>
    Are we talking about this syntax?<br>
    <br>
      %i = alloca f32, align 4, addrspace 5<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
      cite="mid:689be6b4-a619-c04a-43f6-9fc4415c01e0@codeaurora.org"
      type="cite"> <br>
      Otherwise, this seems fine.<br>
      <br>
      <p>-Eli<br>
      </p>
      <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>