llvm dev - Nov 2010 - [LLVMdev] Build Attributes Proposal

Hi Sandeep,
> Another use for build attributes would be as a means to record the
> build flags selected for each translation unit so that LTO could know
> how to optimize/tune the result. This use seems more important to
> solve than the ARM attributes under discussion here.
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?

Ciao,

Duncan.

On Thu, 18 Nov 2010 07:55:00 +0100
Duncan Sands <baldrick at free.fr> wrote:
> Hi Sandeep,
> 
> > Another use for build attributes would be as a means to record the
> > build flags selected for each translation unit so that LTO could
> > know how to optimize/tune the result. This use seems more important
> > to solve than the ARM attributes under discussion here.
> 
> 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?
For GCC's LTO I think the optimization is the one you specify at link
time, the optimization specified at compile time is used only for
preprocessing and native code output. Since LLVM only outputs bitcode
when doing LTO, then I think that leaves us with the optimizatin level
specifeid at link time.

However that breaks the traditional CFLAGS="-O2",
CFLAGS="-O3". You
usually don't need those on the link line, so you may end up with no
optimizations at all. Which is bad, and defeats the purpose of doing
LTO in the first place.
Of course easiest is to just use $CFLAGS on linker line too, but you
never know how someone's build system looks like

The linker could:
 - always override optimization levels by those specified on the linker
   line, if any
 - otherwise fall back to -std-link-opts (you're doing LTO, right?
   means you probably want fast code or you wouldn't be doing LTO in
   the first place), and warn
 - warn if the source files have different optimization levels, or
   different than the one specified at link time.

This avoids an easy pitfall (no opt level specified on linker line -O0 = LTO
gave me worse performance), and works seamlessly if opt level
is specified. It is also compatible with how GCC behaves.

Best regards,
--Edwin

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>

On Thu, Nov 18, 2010 at 6:55 AM, Duncan Sands <baldrick at free.fr>
wrote:
>
>> Another use for build attributes would be as a means to record the
>> build flags selected for each translation unit so that LTO could know
>> how to optimize/tune the result. This use seems more important to
>> solve than the ARM attributes under discussion here.
>
> 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?
I wasn't so much worried about -O level, but processor tuning
selection, float ABI, etc. For example, one might build most code with
Thumb and then build some hot code as ARM. Or perhaps one builds code
with and without NEON and conditionally decides which code to run at a
higher level.

deep

On 18 November 2010 18:15, Devang Patel <dpatel at apple.com>
wrote:
> 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.
I agree. LTO is a linker option and AFAIK there isn't a level (like
-O). The only place where it could make sense is to automatically
choose LTO on -O3, but I'm not sure what are the catches if you do
that and that is more of a convenience nature than anything else.

> 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.
How is this passed through bitcode?

> I think, letting user select optimization passes at link time adds extra
> knobs for user to waste time without giving them significant benefits.
I agree. We should focus only on the things that cannot be expressed
by any other means and could have potential problems that cannot be
easily caught during compile time.

Instruction set, architecture parameters, processor tuning, float ABI
and optimization levels can all be resolved one way or another.
However, special features like prohibiting NEON on A9, or the use of a
specific instruction set cannot be expressed in IR and might have
consequences if you keep your intermediates in bitcode format (like
most JIT environments).

True, you can guess that if the IR doesn't have a single aapcs vfp
attribute, it probably won't have NEON and vice-versa, but that's a
dangerous assumption, as not always true.

cheers,
--renato