[PATCH] Add -disable-opt option to LTO

[Bill Wendling]

Calling this flag (and others like it) a "bug" is a bit harsh, in my opinion. Undesirable, sure, but an acceptable workaround until we can get proper support for determining which passes to run during LTO. I think we should have support in LTO for the `-O' flags: `-O0' turns off optimizations, `-O1' turns on a few, etc. The rationale is because this is the granularity of control that clang gives users when they're doing non-LTO builds. The only reason to have a finer grained control over which passes are run is for debugging purposes.

-bw

On Mar 3, 2013, at 5:12 PM, Cristiano Giuffrida <c.giuffrida at vu.nl> wrote:

> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits