<p dir="ltr"><br>
On Apr 24, 2013 3:28 PM, "Andrew Trick" <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br>
><br>
><br>
> On Apr 24, 2013, at 12:17 PM, Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>
><br>
>> Given that we have the optimization implemented in both SimplifyCFG and the Early-If converter now, I believe we can take a pragmatic approach:<br>
>><br>
>> * Enable the SimplifyCFG optimization now. This will allow us not to look bad on Phoronix/hmmer and spec/hmmer in llvm 3.3 (20%!). And it seems people agree that this is generally a good thing in the current compilation pipeline.<br>
>> and<br>
>> * Add the Early If-converter solution. This is the future proof approach. Once we get rid of the select cannonicalization and enable the early-ifconverter we have this to fall back on.<br>
>><br>
>><br>
>> What do you think?<br>
><br>
><br>
> As long as we don't introduce target heuristics in the early SimplifyCFG passes, it shouldn't be a problem. It is certainly possible for targets to reverse-if-convert if needed.</p>
<p dir="ltr">I'm (unsurprisingly) fine with this as a short the solution -- I originally tried to do the same. I would check whether this handles the clamping loop in zlib while you're trying to avoid huge performance problems, it caused a 20% regression on zlib benchmarks similar to the ones you cite and it is a similarly trivial case.</p>
<p dir="ltr">I'm not actually too worried about target specifics here... I don't think they belong in the simplify cfg pass but I view this all as very temporary anyways. Hopefully you won't even need anything.</p>
<p dir="ltr">><br>
> Long-term I agree with Chandler. I don't like GVN and other high level opts growing dependent on selects that are only formed in a small subset of the cases in which optimization should apply. That is clearly anti-canonical. To be rehashed after ISEL is fixed...<br>
><br>
> -Andy<br>
><br>
>> On Apr 24, 2013, at 1:47 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
>><br>
>>> I generally agree with Chris's position in the here-and-now FWIW. We should continue to balance the IR-level if-conversion for canonicalization against the down sides.<br>
>>><br>
>>> However, I wanted to point out that increasingly I have a different long-term hope for this type of canonicalization that has been heavily influenced by Evan, Andy, Jakob, and Dan Gohman's problems with doing canonicalizations like this at the IR level:<br>
>>><br>
>>> On Wed, Apr 24, 2013 at 7:37 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
>>> On Apr 24, 2013, at 11:28 AM, Shuxin Yang <<a href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> Because this is a canonicalization of this sort, it seems clearly good to do on IR, and early. Doing something like this at the codegen level specifically for micro-architectural reasons could also make sense, but I don't see that eliminating the usefulness of doing it early as well.<br>
>>>><br>
>>>> Introducing a "select" at IR level dose not necessarily means CodeGen convert the "select" with predicated instruction like cmov.<br>
>>>> cmov is not necessary inexpensive, for example, on Pentium 4, the latency of cmov is about 10+ cycle. <br>
>>><br>
>>><br>
>>> Yes, I truly understand that. My point is that it is still a canonicalization: depending on how the user wrote the code is silly for the opposite reason: if they wrote code with ?: or max on pentium 4, codegen should convert it to an "if" if the branch is biased.<br>
>>><br>
>>> I feel like we need a better strategy long-term. Increasingly, I'm of the opinion that as we move away from the SelectionDAG's basic block limitations, we should also move away from canonicalizing to the if-converted code. These days I would rather see us add utilities to LLVM to look across basic blocks which form PHI-only CFGs as-if they were straight line code, and to have the canonical form of predicated values be PHI-only CFGs. This has a nice advantage of simplifying the IR model, and being strictly more general than selects. However, it *requires* that we don't have a basic-block granularity hard limitation in passes, and that's just not the world we live in currently. Maybe eventually.<br>
>>> _______________________________________________<br>
>>> llvm-commits mailing list<br>
>>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
</p>