[PATCH] Add -disable-opt option to LTO

[Cristiano Giuffrida]

Hi,
I couldn't agree more that a proper interface (and a C API used by the
gold plugin) is needed to control libLTO. And yes, -disable-opt and
(the existing) -disable-inlining command-line flags in libLTO may be
considered "bugs" if you look at the big picture, but so is hardcoding
the LTO passes to run in libLTO (which is what we currently have). As
I mentioned in my previous email, this is only a (small) first step to
make things easier until the interface is reworked properly.

Cristiano

On Mon, Mar 4, 2013 at 12:24 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Cristiano Giuffrida wrote:
>> Hi,
>> the attached patch adds the -disable-opt option to LTO. The effect is
>> self-explanatory. I think this should be considered for merging
>> (hopefully for the upcoming 3.3 release) for the following reasons:
>
> I appreciate these goals, but I don't like the approach. libLTO
> shouldn't have these command-line flags at all, both of those are bugs.
> It should be entirely controllable through a proper C API.
>
>  > - Debugging gold plugin-based linking without optimizations getting
> in the way.
>
> If you want to add a flag to the gold plugin, please add it to the gold
> plugin. I don't know offhand whether this necessitates extending the
> libLTO interface, but it wouldn't surprise me.
>
>  > - Debugging programs linked with the gold plugin while preserving the
>  > original debug info.
>
> Ditto.
>
>> - Consistency with opt (which supports the same option with the same
>> meaning and description).
>
> How would this work? The C API is intended to be high-level and ABI
> stable across many llvm revisions. This means that llvm should be able
> to create and delete LTO passes without the need to recompile any libLTO
> clients.
>
>> - Fine-grained control over LTO passes using the gold plugin in
>> combination with opt (or clang/dragonegg).
>
> Ditto.
>
> Nick