[LLVMdev] Build Attributes Proposal

Renato Golin rengolin at systemcall.org
Thu Nov 18 13:09:00 PST 2010


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



More information about the llvm-dev mailing list