[PATCH] D21315: Reorder SimplifyCFG and SROA?

Thomas Jablin via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 13 16:31:53 PDT 2016

tjablin created this revision.
tjablin added reviewers: hfinkel, cycheng, chandlerc.
tjablin added a subscriber: llvm-commits.
Herald added a subscriber: mehdi_amini.

I'd like to propose changing the order of the SimplifyCFG and SROA passes run. There are optimizations in SimplifyCFG that are enabled by SROA. Presently, SimplifyCFG is run before and after SROA, but some less advantageous SimplifyCFG transformations can run in the first pass and deny better SimplifyCFG transformations a chance. Changing the order of these two passes will resolve performance bug 27555 (https://llvm.org/bugs/show_bug.cgi?id=27555). I don't know how the ordering of these two passes was decided initially, so I am hoping whether this order was deliberate.

Specifically, there are two functions in SimplifyCFG and deal with long sequences of comparisons: FoldValueComparisonIntoPredecessors and FoldingBranchToCommonDest. These two transformations have overlapping opportunities, but when both are applicable, FoldValueComparisonIntoPredecessors is typically better. Presently, even though FoldValueComparisonIntoPredecessors runs before FoldingBranchToCommonDest, FoldingBranchToCommonDest wins, because FoldValueComparisonIntoPredecessors needs to run after values are promoted to registers, whereas FoldingBranchToCommonDest can run before.

FoldingBranchToCommonDest transforms code that looks like:

if (A) goto LabelX
if (B) goto LabelX
if (C) goto LabelX
goto LabelY


if(A || B || C || ...) goto LabelX
goto LabelY

where A, B, C, etc are non-side-effecting expressions.

FoldValueComparisonIntoPredecessors transforms code that looks like:

if (x == A) goto LabelX
if (x == B) goto LabelY
if (x == C) goto LabelZ

select(x) {
  case A: goto LabelX
  case B: goto LabelY
  case C: goto LabelZ

where A, B, C, etc are constant values.

In situations where both transformations apply, FoldValueComparisonIntoPredecessors tends to be better, since LLVM can lower the Select more efficiently than the complex boolean expression generated by FoldingBranchToCommonDest.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D21315.60625.patch
Type: text/x-patch
Size: 11512 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/b32ab06c/attachment.bin>

More information about the llvm-commits mailing list