<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 11:46 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><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="h5">
    <p><br>
    </p>
    <div class="m_-5664487713594278861moz-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_-5664487713594278861h5"><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></div></div>
    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.</div></blockquote><div>Of course not, but this  sets it up as an all or nothing thing, and it's not.</div><div>Though you probably will need a stop loss point in the future.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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). </div></blockquote><div>This is not the only effect it will have, and i don't believe you think that either (since this argument is globally applicable to the degree that it would mean we should just accept *every patch* rather than push people to better design stuff). </div><div>It would also, for example, push people towards putting transformations elsewhere.</div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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.</div></blockquote><div> Sure, and frankly, you will never get one until either someone decides to be super-altruistic, or you start pushing on people a little more than "not at all".<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> We should start an RFC and iterate on this until we have a
    concrete plan and migration plan.</div></blockquote><div><br></div><div>I don't believe that will actually achieve anything at this point (really, no offense meant)</div><div>So  I'm just going to leave this stuff alone since it's pretty clear people just view me as being either obstructionist or unrealistic.</div><div><br></div><div>I don't see anything happening until we are willing to push more, and i don't see that happening until instcombine is even worse than it is now.</div><div><br></div></div></div></div>