<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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>
    <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>
  </body>
</html>