<div dir="ltr">Nice to have metrics - so thanks for mentioning that, even if it doesn't end up being suitable, it's certainly worth looking at.<br><br>Did you do anything similar for the values of variables? I could imagine "printing the value of a variable" (not necessarily being able to modify it) at all those locations should render the same value (not undefined).<br><br>& to me, that's actually where I would've guessed -Og (which might be a better discussion for a separate thread, to be honest - as much as it was brought up in the subject of this thread) would diverge from -O1. Doing things like "leaking the value of any variable at the end of its scope" to avoid dead store/unused value elimination ("oh, we saw the last use of this variable half way through the function, so we reused its register for something else later on") - and that's a case where that behavior can't really (that I can think of) be justified to be unconditional at -O1 (because it pessimizes the code in a way that /only/ gives improvements to a debugger, really) - though I'm happy to be wrong/hear other opinions on that.<br><br>So my model is more "-Og would be an even more pessimized -O1" (or potentially -Og isn't really an optimization level, but an orthogonal setting to optimization that does things like actively pessimize certain features to make them more debuggable somewhat independently of what optimizations are used - sort of like the sanitizers) but perhaps that's inconsistent with what other folks have in mind.<br><br>- Dave<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 6:41 AM via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_3104806002293936010WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Awesome start.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Back when I did a similar project at HP/NonStop, the class of optimizations we turned off for our O1 (Og equivalent) tended to be those that reordered code
or otherwise messed with the CFG. In fact one of our metrics was:<u></u><u></u></span></p>
<p class="m_3104806002293936010MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The set of breakpoint locations available at Og should be the same as those available at O0.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This is pretty easy to measure. It can mean either turning off optimizations or doing a better job with the line table; either way you get the preferred user
experience. Not saying *Clang* has to use the "must be the same" criterion, but being able to measure this will be extremely helpful. Comparing the metric with/without a given pass will give us a good idea of how much that pass damages the single-stepping
experience, and gives us hard data to decide whether certain passes should stay or go.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I don't remember whether HP/NonStop turned off constant/value propagation, but I *think* we did, because that can have a really bad effect on availability of
variables. Now, if we're more industrious about generating DIExpressions to recover values that get optimized away, that's probably good enough, as usually you want to be looking at things and not so much modifying things during a debugging session.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As for Sony's users in particular, working in a real-time environment does constrain how much performance we can give away for other benefits like good debugging.
I think we'll have to see how that falls out.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_3104806002293936010WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><a name="m_3104806002293936010__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Greg Bedwell via llvm-dev<br>
<b>Sent:</b> Friday, March 29, 2019 8:25 AM<br>
<b>To:</b> Eric Christopher<br>
<b>Cc:</b> llvm-dev; Ahmed Bougacha; Petr Hosek<br>
<b>Subject:</b> Re: [llvm-dev] Proposal for O1/Og Optimization and Code Generation Pipeline<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Thanks for posting this. I'm absolutely of the opinion that current -O1 is almost a "worst of all worlds" optimization level, where the performance of the generated code isn't good enough to be particularly useful (for our users at least)
but the debug experience is already getting close to being as bad as -O2/3, so I'm personally very happy with your direction of redefining -O1 (especially as that could then open up the way to future enhancements like using PGO data to let us compile everything
at -O1 for the build time performance win, except for the critical hot functions that get the full -O2/3 pipeline for the run time performance win). <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">How will this optimization level interact with LTO (specifically ThinLTO)? Would -O1 -flto=thin to run through a different, faster LTO pipeline or are we expecting that any everyday development build configuration won't include LTO?<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm a little bit more on the fence with what this would mean for -Og, as I'd really like to try and come to some sort of community consensus on exactly what -Og should mean and what its aims should be. If you happen to be at EuroLLVM this
year then that would be absolutely perfect timing as I'd already submitted a round table topic to try and start just that process [ <a href="http://llvm.org/devmtg/2019-04/#rounds" target="_blank">http://llvm.org/devmtg/2019-04/#rounds</a> ]. My team's main
focus right now is in trying to fix as many -O2 debug experience issues as possible, with the hope that we could consider using an -Og mode to mop up what's left, but we've been surveying our users for a few years now about what they'd find useful in such
an optimization level.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The general consensus is that performance must not be significantly worse than -O2. We've heard a few numbers thrown around like 5-10% runtime slowdown compared to -O2 being the absolute maximum acceptable level of intrusion for them to
consider using such a mode. I'm not really sure how realistic that is and I'm inclined to think that we could probably stretch that limit a little bit here and there if the debugging experience really was that much better, but I think it gives a good indication
of at least what our users are looking for. Essentially -O2 but with as few changes as we can get away with making to make the debugging experience better. I know that this is somewhat woolly, so it might be that your proposed pipeline is the closest we
can get that matches such an aim, but once we've decided what -Og should mean, I'd like to try and justify any changes with some real data. I'm willing for my team to contribute as much data as we can. We've also been using dexter [ <a href="http://llvm.org/devmtg/2018-04/slides/Bedwell-Measuring_the_User_Debugging_Experience.pdf" target="_blank">http://llvm.org/devmtg/2018-04/slides/Bedwell-Measuring_the_User_Debugging_Experience.pdf</a> ]
to target our -O2 debugging improvement work, but hopefully it will be useful to provide another datapoint for the effects on the debugging experience of disabling specific passes.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In my mind, -Og probably would incorporate a few things:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* Tweak certain pass behaviors in order to be more favorable towards debugging [ <a href="https://reviews.llvm.org/D59431#1437716" target="_blank">https://reviews.llvm.org/D59431#1437716</a> ]<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* Enable features favorable to debugging [ <a href="http://llvm.org/devmtg/2017-10/#lightning8" target="_blank">http://llvm.org/devmtg/2017-10/#lightning8</a> ]<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* Disable whole passes that are known to fundamentally harm the debugging experience if there is no other alternative approach (this proposal?)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* Still give a decent debug experience when used in conjunction with LTO.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks again for writing up your proposal. I'm really happy to see movement in this area!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Greg<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, 29 Mar 2019 at 02:09, Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>