LLVM Optimization Remarks - Ofek Shilon - CppCon 2022

cppcon.org/
---
LLVM Optimization Remarks - Helping the Compiler Generate Better Code - Ofek Shilon - CppCon 2022
github.com/Cpp...
Optimization remarks are Clang's logs of optimization passes, which include leads into optimization failures that might be mitigated. Deciphering raw optimization remarks seems a matter for compiler authors and select few experts, but a little-known tool called opt-viewer aims to change that - in particular with recent improvements by myself and others.
About 50% of the talk would be dedicated to real examples of missed optimizations. Most turn out to be escape-analysis and alias-analysis related, and we will devote time to discuss these in some depth.
We will also extend the discussion to other compilers and even other languages. (you really can't have a C++ presentation in Sep 2022 without at least mentioning Rust and Carbon).
If you care about performance there's an excellent chance you'd leave this talk with immediately actionable insights and surprising ways to check and improve your code in performance bottlenecks.
---
Ofek Shilon
20Y C++ developer, writer and speaker in both the Linux and MS universes. Fascinated by compilers, debuggers and pretty much anything low level. Fiercely hated by his cat for no apparent reason.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd events.digital...
#cppcon #programming #llvm

[@casperes0912]

This man talks like a very good university professor

[@glorioussir9673]

Very useful talk, thank you! If programmers were taught this stuff we would live in a better world...

[@momoanddudu]

Excellent lecture! I enjoyed it and learned a lot. Thank you!
Regarding the third example, declaring somefunc to be constexpr (passing the argument by const reference doesn't preclude the possibility of doing so) would be a standard way to declare it pure.

[@RadimPolasek]

great presentation, thank you

[@piotrarturklos]

This is awesome, I can't wait to make use of it at work.

[@till8413]

exciting!

[@benjaminshinar9509]

great talk!
I was surprised by how much of it I could follow 😁

[@zxuiji]

17:37, there's a better solution to __restrict__, remove that unnecessary & symbol from b

[@LeDabe]

Great.

[@pietro7121]

This was a very nice talk, but why the incredible handsome man near the airplane in the first slide?

[@ProfessorWaltherKotz]

52:50 Fedor Pikus is such a C++ mastermind... omg

[@williamdavidwallace3904]

The absolute most important thing to help the optimizer produce code that works is to write C or C++ code. In both languages it is possible to easily write code that is nearly correct but has undefined behavior in the standard. The optimizer may well produce totally bad object code in such cases. The compiler is often not required to diagnose such situations.

[@BalanNarcis]

Awesome feature! Great talk, thank you!

[@simonhrabec9973]

It would be nice to have the links from the presentation also in the description.

[@abuyoyo31]

Just added a link in a comment

[@abuyoyo31]

Just tried again

[@origamibulldoser1618]

Perfect talk imo

[@antonbikineev8587]

Amazing talk, thanks

[@Moriadin]

excellent talk!

[@simonhrabec9973]

Great talk!

[@dark808bb8]

Very interesting

[@davidsicilia5316]

great talk

[@mohammadmahdifarnia5358]

20:25 I saw earlier that const variables are protected by mprotect function and modifying the const variable causes seg fault in program! I confused..

[@el__nora]

no, Ofek answers this specifically later on towards the end.
if the original variable was created mutable, and then was later made const, then modifying it through indirect access (or even just const_casting away) is not UB. since the compiler has no idea how that variable was created, it could be perfectly fine to modify it, and it cannot rule out the possibility that it will be modified.

[@mohammadmahdifarnia5358]

@@el__nora 👌 54:07

[@dexterman6361]

33:46 wait whaaatt? omg how is that possible

[@masheroz]

The method is const, so you can't modify what the pointer points to, but that doesn't mean you can't modify what it points to.
And you aren't modifying the int member by name, you're "just" changing the information contained at the address that it owns.
I think.

[@abuyoyo31]

I actually learnt at the conference that this is UB - but no compiler will ever be able to detect it.

[@Peregringlk]

Think that no attribute of the class has been modified. The object contains a pointer, and the pointer has not been modified, and the pointed-to object is not const. In other words, if I memcpy the object to a buffer, call the method, and memcpy the object again, both buffer will compare equal. So that's further proof the method does not modify the object, but objects that lives somewhere else.

[@zxuiji]

Here's one thing I don't get, why is on the compiler to do the optimisations? why can't we just produce debug objects only and then tell the linker what type of binary we want to produce, a debug binary, a striped down release binary, a profiled binary, all of those should be the linker's job to produce from the objects we generate, not the compiler's job, since the linker would have access to all the information it would need to identify if some functions could be made smaller as it could go off to the definition of a function and see what it modifies.

[@stragerneds]

That is called LTO or LTCG.

[@niklkelbon3662]

Lineker have no information about language semantic, so it should only link. Compiler + single .obj (unity build), that may be useful for you