<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 16, 2016 at 6:36 PM Quentin Colombet 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi,</div><div><br></div>DAG combiner does indeed optimizations but also canonicalization.<div>The latter, we probably need to keep, the former, we should be able to disable.</div><div><br></div><div>When I asked Marianne to do a RFC about this, I was hoping we could get new ideas on how to tackle this problem.</div><div><br></div><div>I am fine with the approach of disabling the optimizations one by one when we know it is indeed an optimization. However, I am not a fan of having "if (OptLevel == <...>)" scattered all around the place.</div><div>Instead, I would like to have a sort of list of optimizations that differ between the opt level == none and the other opt level, then we run just that list.</div><div><br></div><div>In other words, I was thinking we could have some kind of registration mechanism for each optimization and this is a matter of classifying them.</div><div><br></div><div>Anyhow, what are other people thoughts?</div></div></blockquote><div><br></div><div>I think the hard part here is that we're really, really bad at registration systems. ;]</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I think switching DAGCombine to use a registration system so that we can use that registration system to also declare a classification between optimizations and canonicalizations that are necessary for lowering would be a *huge* change, if a really good one.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">My question is: is it worth that in the face of progress towards global isel? I'm not sure it is, but I'm also not sure it isn't. =/ this seems to be a hard tradeoff question.</span><br></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I wonder, is the sprinkling of conditions in dag combining code for this going to be significantly worse than the existing sprinkling of conditions to select whether a combine is pre- or post-legalization (for each of the different phases of legalization)? If it is going to be significantly less intrusive, then it might make more sense to just hack the DAG combines with conditions to address the immediate problem rather than taking on the whole task of moving to a mechanical dispatching system for combines. If it would make the situation 2x worse though (that is, it has the same level of overhead), then perhaps it does make sense to do the big refactoring first.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">-Chandler</span></div></div></div>