[llvm] r179957 - SimplifyCFG: If convert single conditional stores

[Chandler Carruth]

On Apr 24, 2013 3:28 PM, "Andrew Trick" <atrick at apple.com> wrote:
>
>
> On Apr 24, 2013, at 12:17 PM, Arnold Schwaighofer <aschwaighofer at apple.com>
wrote:
>
>> Given that we have the optimization implemented in both SimplifyCFG and
the Early-If converter now, I believe we can take a pragmatic approach:
>>
>> * 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.
>> and
>> * 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.
>>
>>
>> What do you think?
>
>
> 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.

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.

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.

>
> 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...
>
> -Andy
>
>> On Apr 24, 2013, at 1:47 PM, Chandler Carruth <chandlerc at google.com>
wrote:
>>
>>> 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.
>>>
>>> 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:
>>>
>>> On Wed, Apr 24, 2013 at 7:37 PM, Chris Lattner <clattner at apple.com>
wrote:
>>> On Apr 24, 2013, at 11:28 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Introducing a "select" at IR level dose not necessarily means CodeGen
convert the "select" with predicated instruction like cmov.
>>>> cmov is not necessary inexpensive, for example, on Pentium 4, the
latency of cmov is about 10+ cycle.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130427/6c204136/attachment.html>