[PATCH] D40037: [CallSiteSplitting] Remove some indirection (NFC).
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 15 05:03:50 PST 2017
fhahn added inline comments.
================
Comment at: lib/Transforms/Scalar/CallSiteSplitting.cpp:374
+ // contains the first compare of the OR and OrBB the second.
+ if (Preds[1]->getSinglePredecessor() == Preds[0]) {
+ HeaderBB = Preds[0];
----------------
junbuml wrote:
> In case HeaderBB has more than two successors (e.g, if a switch is it's terminator), this change could allow splitting. If you want to keep this change NFC, the number of successors of HeaderBB may need to be checked.
I think for the OR case the checks for ICMP would catch this case later (as switch for i1 only can have 2 successors I think) , but I could add an explicit check.
================
Comment at: lib/Transforms/Scalar/CallSiteSplitting.cpp:381
+ } else
return false;
----------------
junbuml wrote:
> We also split a call-site if it use a PHI with all constant incoming values. In this case, Preds are not necessarily an OR structure. For example, in the diamond pattern below, we should split the call site.
>
>
> ```
> define i32 @test(i32* %a, i32 %v) {
> entry:
> br i1 undef, label %TBB0, label %TBB1
> TBB0:
> br i1 undef, label %Tail, label %End
> TBB1:
> br i1 undef, label %Tail, label %End
> Tail:
> %p = phi i32[1,%TBB0], [2, %TBB1]
> %r = call i32 @callee(i32* %a, i32 %v, i32 %p)
> ret i32 %r
> End:
> ret i32 %v
> }
>
> ```
Done! I've separated the code paths splitting on PHI and on Or, as they have different legality checks.
https://reviews.llvm.org/D40037
More information about the llvm-commits
mailing list