[patch] simplifyCFG for review

[Ye, Mei]

Hi Chandler


1.       The transformation I added is not “completely target-specific”.   I don’t see why other targets will not benefit from it especially if cost models are reasonable.

2.        The transformation only kicks in at the last pass before CodeGen.   So IR is the same as if you do it the first thing in CodeGen.

3.        There is an agreement that it will be moved into CodeGen or library (plug-in?) when inventories of similar transformations build up.

4.       If you strongly object, I can add an addition pass of  SimplifyCFG as the first thing in the CodeGen.   But this will really bump up our compilation time since we are using on-line compilation model and due to the lack of function call supports in GPU, every function call including library functions are inlined.

-Mei

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Friday, July 26, 2013 9:38 PM
To: Evan Cheng; Andy Trick
Cc: Ye, Mei; llvm-commits at cs.uiuc.edu
Subject: Re: [patch] simplifyCFG for review

Hey Evan, Andy, and others.

On Mon, Jul 15, 2013 at 2:10 PM, Evan Cheng <evan.cheng at apple.com<mailto: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/20130727/ea608197/attachment.html>