[llvm-dev] Proposal for O1/Og Optimization and Code Generation Pipeline
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 1 18:50:45 PDT 2019
On Mon, Apr 1, 2019 at 6:47 PM Eric Christopher <echristo at gmail.com> wrote:
> Hi All,
> Looks like people are generally supportive of the changes to O1 even
> if there's some discussion around O1/Og equivalence that I'll take to
> a separate set of replies. Mostly so that I can get O1 changes
> separate from "new Og pipeline" changes even if I think that's the
> direction we should ultimately go :)
One comment I'll make (as I'm somewhat obviously supportive having
discussed this before):
I think the key thing isn't that we *necessarily* leave -Og here. But that
if we have a good -O1 pipeline and use that as a starting point for -Og,
then we can critically evaluate whether there is something that we would
like to do at -Og but would harm the goals of -O1. If so, that becomes a
much more clear and precise basis for diverging. Until then, I suspect it
would still be a better starting point than -O2.
> In general though I wanted to give a heads up as to the direction I
> was planning on taking things and seeing if anyone necessarily
> disagreed with the general idea. I'll plan on working up a set of pass
> pipeline patches (after some cleanup) and send out some reviews -
> please let me know (privately) if you'd like to be explicitly cc'd on
> any review otherwise I'll probably pick a set of people out of the cc
> line here.
> Thanks a lot for the responses and looking forward to getting some
> changes going in this direction!
> On Thu, Mar 28, 2019 at 7:09 PM Eric Christopher <echristo at gmail.com>
> > Hi All,
> > I’ve been thinking about both O1 and Og optimization levels and have a
> > proposal for an improved O1 that I think overlaps in functionality
> > with our desires for Og. The design goal is to rewrite the O1
> > optimization and code generation pipeline to include the set of
> > optimizations that minimizes build and test time while retaining our
> > ability to debug.
> > This isn’t to minimize efforts around optimized debugging or negate O0
> > builds, but rather to provide a compromise mode that encompasses some
> > of the benefits of both. In effect to create a “build mode for
> > everyday development”.
> > This proposal is a first approximation guess on direction. I’ll be
> > exploring different options and combinations, but I think this is a
> > good place to start for discussion. Unless there are serious
> > objections to the general direction I’d like to get started so we can
> > explore and look at the code as it comes through review.
> > Optimization and Code Generation Pipeline
> > The optimization passes chosen fall into a few main categories,
> > redundancy elimination and basic optimization/abstraction elimination.
> > The idea is that these are going to be the optimizations that a
> > programmer would expect to happen without affecting debugging. This
> > means not eliminating redundant calls or non-redundant loads as those
> > could fail in different ways and locations while executing. These
> > optimizations will also reduce the overall amount of code going to the
> > code generator helping both linker input size and code generation
> > speed.
> > Dead code elimination
> > - Dead code elimination (ADCE, BDCE)
> > - Dead store elimination
> > - Parts of CFG Simplification
> > - Removing branches and dead code paths and not including commoning
> > and speculation
> > Basic Scalar Optimizations
> > - Constant propagation including SCCP and IPCP
> > - Constant merging
> > - Instruction Combining
> > - Inlining: always_inline and normal inlining passes
> > - Memory to register promotion
> > - CSE of “unobservable” operations
> > - Reassociation of expressions
> > - Global optimizations - try to fold globals to constants
> > Loop Optimizations
> > Loop optimizations have some problems around debuggability and
> > observability, but a suggested set of passes would include
> > optimizations that remove abstractions and not ones that necessarily
> > optimize for performance.
> > - Induction Variable Simplification
> > - LICM but not promotion
> > - Trivial Unswitching
> > - Loop rotation
> > - Full loop unrolling
> > - Loop deletion
> > Pass Structure
> > Overall pass ordering will look similar to the existing pass layout in
> > llvm with passes added or subtracted for O1 rather than a new pass
> > ordering. The motivation here is to make the overall proposal easier
> > to understand initially upstream while also maintaining existing pass
> > pipeline synergies between passes.
> > Instruction selection
> > We will use the fast instruction selector (where it exists) for three
> > - Significantly faster code generation than llvm’s dag based
> > instruction selection
> > - Better debugability than selection dag - fewer instructions moved
> > - Fast instruction selection has been optimized somewhat and
> > shouldn’t be an outrageous penalty on most architectures
> > Register allocation
> > The fast register allocator should be used for compilation speed.
> > Thoughts?
> > Thanks!
> > -eric
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev