<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 3:21 PM, Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="">
    <div>On 03/25/2014 02:31 PM, Jingyue Wu
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr"><br>
            <div>However, we have three concerns on this:</div>
            <div>a) I doubt this optimization is valid for all targets,
              because LLVM language reference (<a href="http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction" target="_blank">http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction</a>)
              says addrspacecast "can be a no-op cast or a complex value
              modification, depending on the target and the address
              space pair." <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></div>
    I think most of the simple cast optimizations would be acceptable.
    The addrspacecasted pointer still needs to point to the same memory
    location, so changing an access to use a different address space
    would be OK. I think canonicalizing accesses to use the original
    address space of a casted pointer when possible would make sense.</div></blockquote><div><br></div>"the address space conversion is legal then both result and operand refer to the same memory location". I don't quite understand this sentence. Does the same memory location mean the same numeric value? <div>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="">
<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr">
            <div>b) NVPTX and R600 have different address numbering for
              the generic address space, which makes things more
              complicated. </div>
            <div>c) We don't have a good understanding of the R600
              backend. </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    R600 currently does not support the flat address space instructions
    intended to use for the generic address space. I posted a patch a
    while ago that half added it, which I can try to work on finishing
    if it would help.<br>
    <br>
    I also do not understand how NVPTX uses address spaces, particularly
    how it can use 0 as the the generic address space.</div></blockquote><div><br></div><div>NVPTX backend generates ld.f32 for reading from the generic address space. There's no special machine instruction to read/write from/to the generic address space in R600? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="">
<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr">
            <div>2. How effective do we want this optimization to be? </div>
            <div><br>
            </div>
            <div>In the short term, I want it to be able to eliminate
              unnecessary non-generic-to-generic addrspacecasts the
              front-end generates for the NVPTX target. For example, <br>
            </div>
            <div><br>
            </div>
            <div>%p1 = addrspace i32 addrspace(3)* %p0 to i32*</div>
            <div>%v = load i32* %p1</div>
            <div><br>
            </div>
            <div>=></div>
            <div><br>
            </div>
            <div>%v = load i32 addrspace(3)* %p0</div>
            <div><br>
            </div>
            <div>We want similar optimization for store+addrspacecast
              and gep+addrspacecast as well. </div>
            <div><br>
            </div>
            <div>In a long term, we could for sure improve this
              optimization to handle more instructions and more
              patterns. </div>
            <span></span><br>
          </div>
        </div>
      </div>
    </blockquote></div>
    I believe most of the cast simplifications that apply to bitcasts of
    pointers also apply to addrspacecast. I have some patches waiting
    that extend some of the more basic ones to understand addrspacecast
    (e.g.
    <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140120/202296.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140120/202296.html</a>),
    plus a few more that I haven't posted yet. Mostly they are little
    cast simplifications like your example in instcombine, but also SROA
    to eliminate allocas that are addrspacecasted.</div></blockquote><div><br></div><div>We also think InstCombine is a good place to put this optimization, if we decide to go with target-independent. Looking forward to your patches! </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><font color="#888888"><br>

    <br>
    -Matt<br>
  </font></span></div>

</blockquote></div><br></div></div>