<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 9, 2016 at 11:56 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</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="gmail-">
    <p>On 12/09/2016 08:45 AM, Reid Kleckner
      via llvm-dev wrote:<br></p>
    <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></span>
    I'm concerned by this response on multiple levels.  I agree Mehdi
    that the proposed IR change seems to be solving a (relatively minor)
    optimization problem with an IR change.  We generally expect our IR
    changes to be well justified and this doesn't even come close to
    me.  More than that, I'm really concerned about the assumption that
    the IR should be a close fit *for a particular frontend* in a
    *particular mode of operation*.  We have tried very hard to keep the
    IR generic enough to be useful by many language frontends and this
    would seem to give up on that goal.  That is deeply concerning  to
    me.<br></div></blockquote><div><br></div><div>I wouldn't be doing this if I thought it was a minor optimization, but in fairness, I haven't measured how much of a win this is yet. The fact that this change solves two separate but related problems in optimized code and unoptimized code is what makes me think this is a good idea.</div><div><br></div><div>I don't see how my proposal favors a particular frontend. The pattern of creating an alloca and storing to it is the recommended way to create mutable local variables (<a href="http://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas">http://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas</a>). We can document the new more efficient idiom if we decide to implement it. Frontends that generate SSA directly are interesting, but I think it's fair for us to optimize for frontends using allocas.</div><div><br></div><div>This should also be a generic improvement across all targets, even if it is more of a win on targets with fewer register parameters. If you have enough arguments, eventually some of them will be passed in memory, unless you have a virtual ISA with an infinite register file.</div><div> </div><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">
    As it stands right now, based on what I've seen to date in
    discussion, I would be strongly opposed to this proposal.  <br></div></blockquote><div><br></div><div>Darn. :)</div></div></div></div>