<div dir="ltr"><div><div>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.<br>
</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 28, 2014 at 2:28 PM, Krzysztof Parzyszek <span dir="ltr"><<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<span><font color="#888888"><br>
<br>
-Krzysztof</font></span><div><br>
<br>
<br>
On 4/28/2014 2:03 PM, Dan Gohman wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
<br>
On Mon, Apr 28, 2014 at 10:11 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a><br></div><div>
<mailto:<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>>> wrote:<br>
<br>
+Dan<br>
On Apr 28, 2014, at 10:01 AM, Krzysztof Parzyszek<br></div><div><div>
<<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a> <mailto:<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.<u></u>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<br>
combine to<br>
>> be run before any target independent DAG combine.<br>
>> This was rejected at the time:<br>
>><br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163692.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvm-commits/Week-<u></u>of-Mon-20130128/163692.html</a><br>
><br>
> There is a claim there that "this is counter to the design of the<br>
DAG combiner", and that the design was modeled after instr-combiner,<br>
but there was no word about why this was made into a design<br>
principle. What was the reason behind this attempt at<br>
canonicalization? Does anyone remember?<br>
<br>
<br>
I didn't design it, but I can explain it; DAG combine utilizes a kind of<br>
canonical form for similar reasons to instcombine's. If there are N<br>
equivalent forms of an expression and M places which care about that<br>
expression, it's nicer to have N patterns for matching them in one place<br>
which canonicalizes them and one pattern in M places that recognize it<br>
than N patterns in M places each. This is not the only relevant design<br>
consideration, but it is a relevant design consideration. The LLVM<br>
community has repeatedly denied requests for instcombine hooks to allow<br>
targets to customize its behavior. The belief is that it's better to<br>
make some targets to a little extra work to match instcombine's<br>
preferred form than to burden other target-independent optimizations<br>
with dealing with multiple forms. In DAG combine the motivation is<br>
somewhat weaker, and in practice its canonical form is somewhat weaker,<br>
but it's still there and it still matters.<br>
<br>
And as I said in that other thread, this isn't an absolute, but it is<br>
something which should be weighed, especially when considering changes<br>
of significant import like adding a new pass or a new set of target<br>
hooks which run from yet another subtly different context within<br>
SelectionDAG.<br>
<br>
Dan<br>
<br>
</div></div></blockquote>
<br><div><div>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<br>
</div></div></blockquote></div><br></div><div><div></div></div></div>