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

[Dan Gohman]

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> 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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140429/b55f6b66/attachment.html>