[cfe-dev] Which optimizations are done by Clang, not LLVM

[John McCall via cfe-dev]

> On Oct 29, 2018, at 1:51 PM, via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> IIRC, Clang CodeGen will do some branch-to-branch elimination, for blocks that are empty/missing at the source level.  Then you have language-mandated things like RVO?  But yeah, the front-end generally doesn't want to do optimizations.

We do a variety of optimizations in the frontend; we just don't think about most of them as optimizations because they're fairly easy and we always do them.  For example, we devirtualize calls to virtual methods on local variables.

LLVM IR is poorly suited for many high-level optimizations because:
  - lowering to IR eliminates a lot of precise type and declaration information
  - lowering to IR makes it difficult to reason about the provenance of values at the right abstraction level for high-level optimization rules (e.g. all the stuff with pointer laundering for C++ devirtualization)
  - lowering to IR generally requires committing to concrete representations in ways that can inhibit or complicate optimizations (e.g. low-level value-copying routines that don't return anything that can serve as a value def for the copy)
  - IR-based optimizations tend to be abstract in ways that require uncomfortable trade-offs to enable (e.g. eagerly emitting TBAA metadata on every memory access, or eagerly instantiating and emitting inline functions for C++ devirtualization)
  - IR-based optimizations often require circumlocutions that interact poorly with other optimizations or otherwise prove unexpectedly difficult to lower to an optimal form (e.g. loads performed for llvm.expect)
  - high-level optimizations often have special-case exceptions which require extensions in order to express in IR or else the optimization has serious soundness problems (e.g. a number of cases with un-referenceable functions in v-tables)

Often we have a simple, local version of the optimization that we can do easily in the frontend which catches a lot of important use cases, and then extending that to cover more cases using LLVM-based data flow optimizations is a major research project.  RVO/NRVO are exceptions only in that their simple, local versions are the only ones actually allowed.

John.

> --paulr
>   <>
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via cfe-dev
> Sent: Monday, October 29, 2018 11:00 AM
> To: Alexander Zaitsev
> Cc: Clang Dev
> Subject: Re: [cfe-dev] Which optimizations are done by Clang, not LLVM
>  
> Very few, if any, optimizations are done by Clang - where possible Clang augments the LLVM IR with extra information to enable LLVM to perform the optimizations.
> 
> Clang's IR generation does vary depending on optimization level - but usually on in this sort of attribute-application context. (eg: applying the 'inlinehint' attribute above -O0, applying the 'optnone' attribute at -O0, etc).
> 
> Maybe some of the memcpy optimization (turning struct copying into memcpies) is done in the frontend - because it knows it can copy around the padding bytes if that's more convenient.
> 
> Even very C++-y things like devirtualization are still, ideally, implemented in LLVM - trying to provide as general a tool as possible for frontends to express these kinds of constraints to the LLVM optimization pipeline.
> 
> - Dave
>  
> On Mon, Oct 29, 2018 at 4:21 AM Alexander Zaitsev via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hello.
> 
> I am trying to find in Clang sources which kind of optimizations do
> directly Clang, not LLVM. What I want to do - I have some ideas for
> optimization which can be done only for C++ code. And as I understand
> Clang is the right place for doing this but I cannot find any example.
> 
> Can you help me a little bit and provide any existent example in Clang
> sources?
> 
> Thank you.
> 
> -- 
> Best regards,
> Alexander Zaitsev
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>_______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181029/f0154507/attachment.html>