[PATCH] Move StructurizeCFG out of R600 to generic Transforms
Owen Anderson
resistor at mac.com
Wed Jun 5 12:55:50 PDT 2013
Hey,
I have a serious question about this patch that I raised in a prior email, and I'd appreciate it if you'd address it rather than continuing in the opposite direction.
On Jun 5, 2013, at 12:42 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
> Move NearestCommonDominator to separate file
>
> http://llvm-reviews.chandlerc.com/D906
>
> CHANGE SINCE LAST DIFF
> http://llvm-reviews.chandlerc.com/D906?vs=2252&id=2279#toc
>
> Files:
> include/llvm/Analysis/NearestCommonDominator.h
I don't understand why this analysis is necessary. We already have pair-wise nearestCommonDominator functionality built into DomTree. If it needs to be extended to support multi-block NCD queries, that should be possible to implement on top of the existing functionality rather than build a new analysis on top of it.
> include/llvm/InitializePasses.h
> include/llvm/LinkAllPasses.h
> include/llvm/Transforms/Scalar.h
> lib/Target/R600/AMDGPUStructurizeCFG.cpp
> lib/Target/R600/AMDGPUTargetMachine.cpp
> lib/Target/R600/CMakeLists.txt
> lib/Transforms/Scalar/CMakeLists.txt
> lib/Transforms/Scalar/Scalar.cpp
> lib/Transforms/Scalar/StructurizeCFG.cpp
More generally, I don't understand why it's desirable to move this out of the R600 target. The comments hand wave about it being useful for other targets, but I don't see anyone actually planning to use it. If there is interest in it from other targets, then you probably need to start by having a conversation with other target authors about what kind of common canonical form different targets can share rather than simply foisting whatever was convenient for R600 onto them.
--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130605/7b47bdd6/attachment.html>
More information about the llvm-commits
mailing list