[PATCH] D16637: [SimplifyCFG] limit recursion depth when speculating instructions (PR26308)
Daniel Berlin via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 27 10:25:48 PST 2016
Errr, rather than limit recursion depth, why not just keep track of what's
visited and avoid the cycles?
(You could also cheaply build sccs of the instruction and it's uses, and
decide what to do for each SCC as a whole, which would avoid this issue as
well)
On Wed, Jan 27, 2016 at 10:10 AM, Sanjay Patel via llvm-commits <
llvm-commits at lists.llvm.org> wrote:
> spatel created this revision.
> spatel added reviewers: majnemer, jmolloy.
> spatel added a subscriber: llvm-commits.
> Herald added a subscriber: mcrosier.
>
> This is a fix for:
> https://llvm.org/bugs/show_bug.cgi?id=26308
>
> With the switch to using the TTI cost model in:
> http://reviews.llvm.org/rL228826
> ...it became possible to hit a zero-cost cycle of instructions (gep -> phi
> -> gep...), so we need a cap for the recursion in DominatesMergePoint().
>
> A recursion depth parameter was already added for a different reason in:
> http://reviews.llvm.org/rL255660
> ...so I think we just need to set a limit.
>
> I pulled "10" out of the air and made it an independent parameter that we
> can play with. It might be higher than it needs to be given the currently
> low default value of PHINodeFoldingThreshold (2). That's the starting cost
> value that we enter the recursion with, and most instructions have cost set
> to TCC_Basic (1), so I don't think we're going to speculate more than 2
> instructions with the current parameters.
>
> http://reviews.llvm.org/D16637
>
> Files:
> lib/Transforms/Utils/SimplifyCFG.cpp
> test/Transforms/SimplifyCFG/X86/switch_to_lookup_table.ll
>
> Index: test/Transforms/SimplifyCFG/X86/switch_to_lookup_table.ll
> ===================================================================
> --- test/Transforms/SimplifyCFG/X86/switch_to_lookup_table.ll
> +++ test/Transforms/SimplifyCFG/X86/switch_to_lookup_table.ll
> @@ -1302,3 +1302,35 @@
> ; CHECK: entry
> ; CHECK-NEXT: switch
> }
> +
> +; Speculation depth must be limited to avoid a zero-cost instruction
> cycle.
> +
> +; CHECK-LABEL: @PR26308(
> +; CHECK: cleanup4:
> +; CHECK-NEXT: br label %cleanup4
> +
> +define i32 @PR26308(i1 %B, i64 %load) {
> +entry:
> + br label %while.body
> +
> +while.body:
> + br label %cleanup
> +
> +cleanup:
> + %cleanup.dest.slot.0 = phi i1 [ false, %while.body ]
> + br i1 %cleanup.dest.slot.0, label %for.cond, label %cleanup4
> +
> +for.cond:
> + %e.0 = phi i64* [ undef, %cleanup ], [ %incdec.ptr, %for.cond2 ]
> + %pi = ptrtoint i64* %e.0 to i64
> + %incdec.ptr = getelementptr inbounds i64, i64* %e.0, i64 1
> + br label %for.cond2
> +
> +for.cond2:
> + %storemerge = phi i64 [ %pi, %for.cond ], [ %load, %for.cond2 ]
> + br i1 %B, label %for.cond2, label %for.cond
> +
> +cleanup4:
> + br label %while.body
> +}
> +
> Index: lib/Transforms/Utils/SimplifyCFG.cpp
> ===================================================================
> --- lib/Transforms/Utils/SimplifyCFG.cpp
> +++ lib/Transforms/Utils/SimplifyCFG.cpp
> @@ -90,6 +90,11 @@
> cl::desc("Allow exactly one expensive instruction to be speculatively
> "
> "executed"));
>
> +static cl::opt<unsigned> MaxSpeculationDepth(
> + "max-speculation-depth", cl::Hidden, cl::init(10),
> + cl::desc("Limit maximum recursion depth when calculating costs of "
> + "speculatively executed instructions"));
> +
> STATISTIC(NumBitMaps, "Number of switch instructions turned into
> bitmaps");
> STATISTIC(NumLinearMaps, "Number of switch instructions turned into
> linear mapping");
> STATISTIC(NumLookupTables, "Number of switch instructions turned into
> lookup tables");
> @@ -269,6 +274,11 @@
> unsigned &CostRemaining,
> const TargetTransformInfo &TTI,
> unsigned Depth = 0) {
> + // It is possible to hit a zero-cost cycle (phi/gep instructions for
> example),
> + // so limit the recursion depth.
> + if (Depth == MaxSpeculationDepth)
> + return false;
> +
> Instruction *I = dyn_cast<Instruction>(V);
> if (!I) {
> // Non-instructions all dominate instructions, but not all
> constantexprs
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160127/e9ef2fe1/attachment.html>
More information about the llvm-commits
mailing list