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

[Krzysztof Parzyszek]

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>> wrote:
>
>     +Dan
>     On Apr 28, 2014, at 10:01 AM, Krzysztof Parzyszek
>     <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
>      >
>      > 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