<div dir="ltr">Which is, of course, precisely why I didn't suggest that, it was Hal's straw man.<br>
</div><span>
</span><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 15, 2017, 12:26 PM Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <div class="m_5533082446293145890m_4446434701631465268moz-cite-prefix">On 07/14/2017 11:46 AM, Hal Finkel via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p><br>
      </p>
      <div class="m_5533082446293145890m_4446434701631465268moz-cite-prefix">On 07/14/2017 01:38 PM, Daniel Berlin
        wrote:<br>
      </div>
      <blockquote type="cite">
        
        <div dir="ltr">
          <div class="gmail_extra">
            <div class="gmail_quote">
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div bgcolor="#FFFFFF" text="#000000">
                  <div>
                    <div class="m_5533082446293145890m_4446434701631465268h5"><br>
                    </div>
                  </div>
                  Not sure about this last part. It is really going to
                  require work by us to rewrite things. :-) In the mean
                  time, I think we should go ahead with this.</div>
              </blockquote>
              <div><br>
              </div>
              <div>FWIW: My problem is, when put in this framework, we
                will repeatedly make this same decision, this same way,
                again and again, and never actually get even started on
                fixing it :)</div>
              <div><br>
              </div>
              <div>IE "it's just another small patch!"</div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      You're correct. However, as I'm sure you're aware, developer time
      is not directly transferable in a way that makes any other
      decision optimal. It's not like blocking all improvements to
      InstCombine will cause a movement to appear to rewrite
      InstCombine. It will only cause a shrink in the pool of developers
      with recent experience working on InstCombine (and a lot of
      out-of-tree patches). Frankly, we don't even have a concrete plan
      for how we'd do this, or even a target design, and that's the
      first item on the critical path to a rewrite. We should start an
      RFC and iterate on this until we have a concrete plan and
      migration plan.<br>
    </blockquote></div><div text="#000000" bgcolor="#FFFFFF">
    Just want to chime in here in support of what Hal said.  I strongly
    believe we should not block incremental progress unless we have a
    plan in place for a better design.  In particular, part of being
    able to come up with a better design is having multiple people with
    recent knowledge of the system which needs replaced and stopping
    evolution of the old system by definition inhibits having such a
    group of people.  <br></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Philip<br>
  </div></blockquote></div>