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

[Chandler Carruth]

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