[llvm-dev] [RFC] Disabling DAG combines in /O0

[Quentin Colombet via llvm-dev]

> On May 17, 2016, at 6:39 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> On Mon, May 16, 2016 at 6:36 PM Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi,
> 
> DAG combiner does indeed optimizations but also canonicalization.
> The latter, we probably need to keep, the former, we should be able to disable.
> 
> When I asked Marianne to do a RFC about this, I was hoping we could get new ideas on how to tackle this problem.
> 
> 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.
> 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.
> 
> 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.
> 
> Anyhow, what are other people thoughts?
> 
> I think the hard part here is that we're really, really bad at registration systems. ;]
> 
> 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.
> 
> 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.

Agree, I don’t think it makes sense to do that in SDISel. Though I was curious to have ideas to see how we would tackle that when we eventually do combines in GISel.

> 
> 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.

Agreed.

Q.

> 
> -Chandler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/95917bea/attachment.html>