[llvm-bugs] [Bug 48821] New: Perf regressions with enable-new-pm due to SpeculateAroundPHIs splitting backedges
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Jan 20 08:25:43 PST 2021
https://bugs.llvm.org/show_bug.cgi?id=48821
Bug ID: 48821
Summary: Perf regressions with enable-new-pm due to
SpeculateAroundPHIs splitting backedges
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedbugs at nondot.org
Reporter: bjorn.a.pettersson at ericsson.com
CC: llvm-bugs at lists.llvm.org
Downstream we have seen performance regressions when using -enable-new-pm.
Basically the effect is that our backend passes fail to detect that hardware
loops can be use.
We've tracked it down to the SpecualteAroundPHIs pass modifying loops by doing
splitting on the back edge of the loop. And I wonder if that is expected (and
if there are any examples where it would be profitable to do that).
Consider a test case like this:
define void @hello(i16 %n) {
entry:
%cmp1 = icmp slt i16 %n, 8
br i1 %cmp1, label %for.body, label %for.end
for.body:
%i.02 = phi i16 [ %add, %for.body ], [ 0, %entry ]
%add = add nuw nsw i16 %i.02, 1
%cmp = icmp slt i16 %add, %n
br i1 %cmp, label %for.body, label %for.end
for.end:
ret void
}
when compiled with "opt -passes=spec-phis -S" we get
define void @hello(i16 %n) {
entry:
%cmp1 = icmp slt i16 %n, 8
br i1 %cmp1, label %entry.for.body_crit_edge, label %for.end
entry.for.body_crit_edge:
%add.1 = add nuw nsw i16 0, 1
br label %for.body
for.body:
%add.phi = phi i16 [ %add.0, %for.body.for.body_crit_edge ], [ %add.1,
%entry.for.body_crit_edge ]
%cmp = icmp slt i16 %add.phi, %n
br i1 %cmp, label %for.body.for.body_crit_edge, label %for.end
for.body.for.body_crit_edge:
%add.0 = add nuw nsw i16 %add.phi, 1
br label %for.body
for.end:
ret void
}
Is this a good transformation, or should SpecualateAroundPHIs avoid splitting
backedges?
Note that something like this might do the trick (not sure if it is an ideal
solution though):
diff --git a/llvm/lib/Transforms/Scalar/SpeculateAroundPHIs.cpp
b/llvm/lib/Transforms/Scalar/SpeculateAroundPHIs.cpp
index 9b18c945d950..41377f0572d5 100644
--- a/llvm/lib/Transforms/Scalar/SpeculateAroundPHIs.cpp
+++ b/llvm/lib/Transforms/Scalar/SpeculateAroundPHIs.cpp
@@ -792,6 +792,13 @@ static bool tryToSpeculatePHIs(SmallVectorImpl<PHINode *>
&PNs,
return false;
}
+ for (auto &Pred : PredSet) {
+ if (DT.dominates(PNs[0]->getParent(), Pred)) {
+ LLVM_DEBUG(dbgs() << " Involves a back-edge\n");
+ return false;
+ }
+ }
+
I don't know if any in-tree targets suffers the same way from
SpeculateAroundPHIs. Maybe people could do some benchmarks with the above patch
for their targets to see if there is any impacts.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210120/8e2f1454/attachment.html>
More information about the llvm-bugs
mailing list