[llvm-dev] Proposal for O1/Og Optimization and Code Generation Pipeline

[Kristof Beyls via llvm-dev]

I like the general direction.
Which seems in line with what's written already at
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Passes/PassBuilder.h#L116
(which
is the closest to a written down statement that I know of for what our
optimization levels should aim for).

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.

I agree that we should aim to use data to make tradeoffs.
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?
http://lnt.llvm.org/db_default/v4/nts/124231) 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"?

Thanks,

Kristof

Op vr 29 mrt. 2019 om 06:45 schreef Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org>:

>
>
>
>> >
>> >  - Dead code elimination (ADCE, BDCE)
>>
>>
>> Regarding BDCE: The trivialized values might indeed be irrelevant to
>> later calculations, but might harm the debugging experience? If BDCE
>> only was applied at O2 and higher, that's likely not a huge loss.
>> Regular DCE (meaning without the bit-tracking parts) is probably fine
>> for O1.
>>
>>
>>
> Probably not. I'll see what the impact is for sure.
>
>
>> > Register allocation
>> >
>> > The fast register allocator should be used for compilation speed.
>>
>>
>> I'm not sure about this - we should understand the performance impact -
>> it might be severe.
>>
>>
> 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.
>
> Thanks :)
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190329/e12d2c51/attachment.html>