[patch] FlattenCFG (refactoring)

[Ye, Mei]

Andy

Thanks for your quick response.
W.R.T your question on more CFG transforms,  we have multiple targets that are code-based on LLVM but with minimum code-sharing.   If people can realize that this is not the right approach, sooner or later they will have the motivation to pool a variety of CFG transformations together.   W.R.T the compilation time, it will take some time to change early-inlining to late-inlining.   Before that happens, adding a new pass is prohibited in the target that I am working on.  So there is a code divergence between trunk-push and local development effort.

-Mei

From: Andrew Trick [mailto:atrick at apple.com]
Sent: Friday, August 02, 2013 9:34 AM
To: Ye, Mei
Cc: Chandler Carruth; llvm commits
Subject: Re: [patch] FlattenCFG (refactoring)

On Aug 1, 2013, at 6:42 PM, Ye, Mei <Mei.Ye at amd.com<mailto:Mei.Ye at amd.com>> wrote:


Attached patch re-factor the code out from SimplifyCFG.   Please review.  Thanks a lot.

-Mei
<odc_refactor>

Thanks for making those changes. I'm ok with this patch as-is. A couple questions though:

I thought that FlattenCFGPass would be a target pass, AMDGPUFlattenCFG. Other targets could add their own equivalent pass but may choose to interleave other target-specific CFG transforms. Do you foresee adding more CFG transforms for AMD? If so, you may want to start with this as a target pass so you can extend it incrementally without being forced to checkin to target-independent code.

This is just curiosity, but does this patch measurably increase compile time? If so I'm curious if you can plugin a target-specific inlining pass. That could improve your compile time in general.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130802/0b648803/attachment.html>