<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 10:11 AM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+Dan<br>
<div class="">On Apr 28, 2014, at 10:01 AM, Krzysztof Parzyszek <<a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a>> wrote:<br>
<br>
> On 4/28/2014 11:45 AM, Quentin Colombet wrote:<br>
>> For the record, we’ve already proposed a target-specific DAG combine to<br>
>> be run before any target independent DAG combine.<br>
>> This was rejected at the time:<br>
>> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163692.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163692.html</a><br>
><br>
> 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?<br>

</div> </blockquote><br></div><div class="gmail_quote">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.<br>
<br></div><div class="gmail_quote">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.<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">Dan<br><br></div></div></div>