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