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

[Krzysztof Parzyszek]

Thanks, this gives me a good background on this.  I'm still interested 
in having a discussion on allowing more target-specific control over DAG 
transformations.  I'll start something in a new thread once I take a 
look at the legalization code.

-Krzysztof

On 4/29/2014 11:26 AM, Dan Gohman wrote:
> The DAG combiner runs before several legalization phases, as well as
> DAGCombine itself, not to mention itself within the same pass (it's
> iterative). There are also a variety of advantages from avoiding
> differences between targets when practical. As I indicated, the value of
> canonicalization is lower than in instcombine but it is not zero, so it
> is something to weigh against other concerns.
>
> On Mon, Apr 28, 2014 at 2:28 PM, Krzysztof Parzyszek
> <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote:
>
>     The circumstances regarding inst-combine and DAG-combine are
>     different: the instruction combiner runs in the middle of IR
>     optimizations, which are mostly common for all targets.  DAG
>     combiner runs almost immediately before instruction selection, which
>     is as far from common as you can get.  I don't think that the
>     motivations behind instruction combiner translate directly to the
>     DAG combiner, and even after the explanations, I still don't see any
>     specific reason for trying to canonicalize anything at that time.
>       Who would be the consumer of these canonical forms?  What would be
>     the benefit of having them?  On the contrary, there seems to be
>     interest in having a greater degree of control regarding the final
>     DAG patterns presented to the instruction selector.
>
>     -Krzysztof
>
>
>
>     On 4/28/2014 2:03 PM, Dan Gohman wrote:
>
>
>
>
>         On Mon, Apr 28, 2014 at 10:11 AM, Quentin Colombet
>         <qcolombet at apple.com <mailto:qcolombet at apple.com>
>         <mailto:qcolombet at apple.com <mailto:qcolombet at apple.com>>> wrote:
>
>              +Dan
>              On Apr 28, 2014, at 10:01 AM, Krzysztof Parzyszek
>              <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>
>         <mailto:kparzysz at codeaurora.__org
>         <mailto: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
>         <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
>
>
>
>     --
>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>     hosted by The Linux Foundation
>
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation