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

[Chandler Carruth via llvm-dev]

On Mon, May 16, 2016 at 6:36 PM Quentin Colombet via llvm-dev <
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.

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.

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