[LLVMdev] Build Attributes Proposal

Devang Patel dpatel at apple.com
Thu Nov 18 10:15:48 PST 2010


On Nov 17, 2010, at 10:55 PM, Duncan Sands wrote:

> why not have your build system just pass the appropriate flags directly to the
> linker?  Also, suppose some files were compiled at -O1, others at -O3.  If you
> do LTO then these files will all be linked together and optimized, but at what
> -O level?  I think it would be wrong to have the linker make policy decisions
> like "optimize at the highest -O level seen" or "optimize at the lowest -O level
> seen".  Better to have the user explicitly say what they want.  But in that case
> is there any need to record the -O level in some special way in the module in
> the first place?

IMO, there is no need to make optimization level decision during LTO using either approach, linker command line or recording in bitcode. 

The optimization levels -O1, -O2, -O3 express "selection". These levels select which optimization passes you want to run, which has impact on compile time and disregards for code size issues. In other words, how much rope are you willing to give optimizer to try to get best performance. When you select LTO, it is very clear user wants the optimizer to be aggressive and optimize across modules. So IMO -O3 is implied when linker is given LLVM bitcode file as an input. 

The other kind of optimization flag is -Os. I would say this expresses "flavor". Here usually you are not selecting optimization pass, but you are implicitly selecting various thresholds so that the transformations and code generation pay attention to code size. This should be a choice at LTO and today it is communicated through function attributes in bitcode file.

I think, letting user select optimization passes at link time adds extra knobs for user to waste time without giving them significant benefits.
-
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101118/380f3fba/attachment.html>


More information about the llvm-dev mailing list