<div dir="ltr"><div>Hi Philip,</div><div><br></div><div>Like others, I like where this is going. Like all, I'm worried how much weird stuff will come out of the box. :)</div><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 3 Dec 2021 at 23:27, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Finally, to be explicit, I am using the SCEV use case by way of
      an example only.  There may be other ways that we depend on
      hoisting as a canonical form that I did not happen to think of
      when writing this email.  The burden is on the person or person
      proposing a change to identify any other dependencies, and to
      convince the community they have done so.  Discussion of a testing
      strategy to find those dependencies should be a first class
      concern in any proposal. </p></div></blockquote><div><br></div><div>There are a number of checks in loop optimisations that look beyond SCEV, and all of them will have to learn the new "canonical" forms.</div><div><br></div><div>What I mean is that wherever the ranges, loop dependencies, target legalities will look at could have more than one shape (basically which BB to look for it, how complex the Phi graph is, etc). It should not have to look at *all* BBs in a given function nor build a complete graph of all changes to all variables across all BBs accessible from the loop context. So, perhaps we could propose at least two "canonical" forms (in quotes, because it's more than one), but you get the idea.</div><div><br></div><div>Another issue is a potential cascading inability to perform transformations. If there are passes between LICM and other loop optimisations that happen to (perhaps implicitly) expect hoisted loads and thus fail to transform in case the profiler says LICM shouldn't happen, subsequent passes will have more and more "canonical" patterns to look for, or more likely, will fail to see anything. The potential change to everything that happens after LICM is worrying.</div><div><br></div><div>We already have that problem today, as probably all other compilers do, but we have reached this local minimum by trial and error, and finding a better minimum elsewhere will be an iterative process and likely pass through maximums and create noise, especially in edge cases.</div><div><br></div><div>So the real question to me is: how are we going to guide this through the solution space with minimal disruption while still making progress?</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>