[PATCH] D21143: Include SelectionDAGISel in the opt-bisect process
Kaylor, Andrew via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 6 12:27:58 PDT 2016
Sorry for the delayed response. I've been on vacation.
There is a test (llvm/test /Other/opt-bisect-legacy-pass-manager.ll) that verifies that opt-bisect doesn't skip anything at -O0, that it doesn't break code generation when the opt-bisect-limit is set to zero and that a bisect search finds a pass where a simple function inlining occurs (an arbitrary case selected because it was easy to identify).
I haven't been attempting to verify the bisection of individual passes, but I discovered that this case was missing through a simple local test so maybe that's worth adding.
From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin Bogner
Sent: Friday, June 17, 2016 10:48 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: reviews+D21143+public+7c4431f8f16a8d65 at reviews.llvm.org; llvm-commits at lists.llvm.org
Subject: Re: [PATCH] D21143: Include SelectionDAGISel in the opt-bisect process
Andy Kaylor <andrew.kaylor at intel.com> writes:
> andrew.w.kaylor created this revision.
> andrew.w.kaylor added a reviewer: bogner.
> andrew.w.kaylor added a subscriber: llvm-commits.
> andrew.w.kaylor set the repository for this revision to rL LLVM.
> This patch allows the SelectionDAGISel pass to be put into
> CodeGenOpt::None mode in response to the opt-bisect-limit command line
> option in addition to the OptimizeNone function attribute (the
> skipFunction() call checks both of these conditions).
> See D19172 for details on the opt-bisect implementation.
> I am checking to see if the optimization level is already
> CodeGenOpt::None before calling the skipFunction() method in order to
> avoid introducing test failures in two lit tests which verify that no
> pass is "skipped" by the optnone or opt-bisect options that is
> otherwise run at -O0. Calling skipFunction at -O0 wouldn't actually
> change this pass' behavior, but it would generate a debugging message
> indicating that the pass was being skipped.
I haven't been paying attention to the opt-bisect stuff, but this looks consistent / like it'll do the right thing. Long term we might want to clean up how SDAGISel deals with opt levels, but that shouldn't block anything here.
LGTM. It'd be nice if it came with a test though - Do we have a good way to test opt-bisect?
> rL LLVM
> Index: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
> --- lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
> +++ lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
> @@ -444,7 +444,7 @@
> // Reset OptLevel to None for optnone functions.
> CodeGenOpt::Level NewOptLevel = OptLevel;
> - if (Fn.hasFnAttribute(Attribute::OptimizeNone))
> + if (OptLevel != CodeGenOpt::None && skipFunction(Fn))
> NewOptLevel = CodeGenOpt::None;
> OptLevelChanger OLC(*this, NewOptLevel);
More information about the llvm-commits