[patch] simplifyCFG for review

[Chandler Carruth]

Hey Evan, Andy, and others.

On Mon, Jul 15, 2013 at 2:10 PM, Evan Cheng <evan.cheng at apple.com> wrote:

> I am ok with adding this transformation into simplifycfg and have it
> being controlled by a target hook. I think it's a reasonable compromise for
> now. In the future, once we start to accumulate more GPU specific
> transformations, I'd prefer they get factored out into a separate passes
> (or even libraries).
>

So, I'm really surprised to see this get committed without a discussion on
llvmdev about the fundamental issues presented by this *radical* design
shift in simplifycfg.

A while back, I added a target hook to simplifycfg to do a target-specific
transform (I called it TTI and a cost model, but it's the same thing). You,
Jakob, Andy, and a bunch of other people objected. You presented compelling
arguments, and we went the other way. In fact, you convinced me that
keeping the same canonical CFG structure in the IR-level passes was really
important for canonicalization and other optimization passes. I now share
what I thought were your objections to such IR-level CFG transforms.

And I'm now confused as this patch adds a significantly more invasive
target hook to do a completely target-specific transform to the CFG. This
patch completely changes the idea of canonical CFG structures at the IR
level for one target compared to the other target. I don't really know how
to even work on simplify-cfg any more because I don't know what the
interactions here. This really needs a design discussion not tucked away in
a 40-email long patch review thread. Could one of you or Mei start that? In
particular, I would like a really compelling reason why this isn't done in
a target specific lowering pass, ideally not at the IR level at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130726/6f233571/attachment.html>