<div dir="ltr">I like the general direction.<div>Which seems in line with what's written already at <a href="https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Passes/PassBuilder.h#L116">https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Passes/PassBuilder.h#L116</a> (which is the closest to a written down statement that I know of for what our optimization levels should aim for).</div><div><br></div><div>I think that -O1 and -Og in a perfect world are different optimization levels (aiming for slightly different goals); but also agree that improving the -O1 implementation to get closer to its described goal will also mostly help in making it a reasonable baseline for an -Og optimization level if we decided to introduce that.</div><div><br></div><div>I agree that we should aim to use data to make tradeoffs.</div><div>It's probably relatively easy to collect data on "compile time" and "execution time" metrics; but probably harder on "debuggability". I wonder if the bot Adrian pointed to in the Debug Info BoF (this one? <a href="http://lnt.llvm.org/db_default/v4/nts/124231">http://lnt.llvm.org/db_default/v4/nts/124231</a>) at last LLVM dev meeting could help provide data for that. Or are those metrics too far off from "debuggability as perceived by a human developer"?</div><div><br></div><div>Thanks,</div><div><br></div><div>Kristof</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 29 mrt. 2019 om 06:45 schreef Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div dir="auto"><div><br><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"><br>
><br>
>  - Dead code elimination (ADCE, BDCE)<br>
<br>
<br>
Regarding BDCE: The trivialized values might indeed be irrelevant to<br>
later calculations, but might harm the debugging experience? If BDCE<br>
only was applied at O2 and higher, that's likely not a huge loss.<br>
Regular DCE (meaning without the bit-tracking parts) is probably fine<br>
for O1.<br><br><br></blockquote><div><br></div><div>Probably not. I'll see what the impact is for sure.</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">
> Register allocation<br>
><br>
> The fast register allocator should be used for compilation speed.<br>
<br>
<br>
I'm not sure about this - we should understand the performance impact -<br>
it might be severe.<br><br></blockquote><div><br></div><div>Totally agree. I think evaluating the tradeoffs is going to be key. I also have really no strong opinions and am happy to go where the data takes us.</div><div><br></div><div>Thanks :)</div><div><br></div><div>-eric</div></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>