[llvm] r207301 - [X86] Implement TargetLowering::getScalingFactorCost hook.

[Dan Gohman]

On Mon, Apr 28, 2014 at 10:11 AM, Quentin Colombet <qcolombet at apple.com>wrote:

> +Dan
> On Apr 28, 2014, at 10:01 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org>
> wrote:
>
> > On 4/28/2014 11:45 AM, Quentin Colombet wrote:
> >> For the record, we’ve already proposed a target-specific DAG combine to
> >> be run before any target independent DAG combine.
> >> This was rejected at the time:
> >>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163692.html
> >
> > There is a claim there that "this is counter to the design of the DAG
> combiner", and that the design was modeled after instr-combiner, but there
> was no word about why this was made into a design principle.  What was the
> reason behind this attempt at canonicalization?  Does anyone remember?
>


I didn't design it, but I can explain it; DAG combine utilizes a kind of
canonical form for similar reasons to instcombine's. If there are N
equivalent forms of an expression and M places which care about that
expression, it's nicer to have N patterns for matching them in one place
which canonicalizes them and one pattern in M places that recognize it than
N patterns in M places each. This is not the only relevant design
consideration, but it is a relevant design consideration. The LLVM
community has repeatedly denied requests for instcombine hooks to allow
targets to customize its behavior. The belief is that it's better to make
some targets to a little extra work to match instcombine's preferred form
than to burden other target-independent optimizations with dealing with
multiple forms. In DAG combine the motivation is somewhat weaker, and in
practice its canonical form is somewhat weaker, but it's still there and it
still matters.

And as I said in that other thread, this isn't an absolute, but it is
something which should be weighed, especially when considering changes of
significant import like adding a new pass or a new set of target hooks
which run from yet another subtly different context within SelectionDAG.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140428/b4614065/attachment.html>