<div dir="auto"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="m_-7267374558098249111m_-2252950334366824260m_-9069867827564364381gmail-">
    <div class="m_-7267374558098249111m_-2252950334366824260m_-9069867827564364381gmail-m_-7117265439172886674moz-cite-prefix">On 12/9/2016 8:45 AM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> <wbr>wrote:<br>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div style="word-wrap:break-word">
            <div>So IIUC basically the *only* reason for this IR change
              is that we don’t want to pattern match in debug build?</div>
            <div>I don't understand right now why we wouldn’t want to do
              this?</div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>If we need to pattern match such a basic construct, it
          suggests to me that we have the wrong representation, and we
          should instead make our representation more accurately model
          reality. To me, it feels like this representation allows
          several good things to just "fall out" without any additional
          work, and that suggests it's a good representation.</div>
      </div>
    </blockquote>
    <br></span>
    Mmm... maybe.  The part I really don't like is the implied store:
    there are a lot of transformations which specifically reason about
    store instructions, and they would all need to be fixed to
    specifically deal with "alloca with an argument" so it doesn't block
    optimizations.  Every feature we add to the IR makes it more
    difficult to write IR transformations, and this really doesn't seem
    to carry its own weight.<br>
    <br>
    A couple of other thoughts I had:<br>
    1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument
    !i32 %x", followed by a store.  There's still a little
    pattern-matching involved because the metadata is only a hint, but
    the intent in the IR is more explicit.<br>
    2. We could change the way clang generates function definitions:
    instead of "define void @f(i32 %x)", generate "define void @f(i32*
    byval %px)" if the value is going to end up on the stack.  This
    should work without any changes to the IR.  This is a bad idea if
    we're trying to run optimizations because it obscures data flow, but
    it seems reasonable at -O0.</div></blockquote><div><br></div><div>IMO, the LLVM function definitions should be a straightforward transformation from the C function signatures, and clang should stop mangling the function signatures with its own intimate knowledge of the calling convention rules.</div><div><br></div><div>Instead, clang could emit (still ABI-specific!) annotations on the arguments that communicates the *properties* of the source-language types which affect the ABI. LLVM, then, would use that information to implement the complete calling convention. No counting of numbers of registers in Clang to put "inreg" markers in the right places, or byval, or any of that sort of stuff it has to do today.</div><div><br></div><div>For example, on x86-64 SysV ABI, a complex classification algorithm is run over the fields in an aggregate, to classify each eightbyte quantity into one of several classes (MEMORY, INTEGER, SSE, etc). That must run on the clang side, using source types, but it could send the direct result of the classification to llvm, rather than using it to mangle the prototype of the function in a secret undocumented handshake using the few seemingly-but-not-really-generic attributes that are available now.</div><div><br></div><div><div>For that reason, I really don't like the second option you mention above, as it requires clang to know more about exactly what the calling convention decisions made by llvm are going to be.</div></div><div dir="auto"><br></div><div dir="auto">Actually, I think byval should be deleted entirely. If you want to pass by value...then, pass by value...</div></div></div></div></div>