[llvm-dev] RFC: LTO should use -disable-llvm-verifier

Duncan P. N. Exon Smith via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 15 15:31:07 PDT 2015


> On 2015-Sep-02, at 19:31, Peter Collingbourne <peter at pcc.me.uk> wrote:
> 
> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote:
>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith <
>> dexonsmith at apple.com> wrote:
>> 
>>> 
>>>> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <
>>> dexonsmith at apple.com> wrote:
>>>> 
>>>>> On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote:
>>>>> Yep. This is where I was going :)
>>>> 
>>>> Glad I found consensus, but I want to double-check that this makes
>>>> sense to add to the driver.  I didn't quite think through the
>>>> implications myself.
>>>> 
>>>> Since the driver doesn't know if there's any bitcode, or if LTO is
>>>> going to be invoked, it seems like I'll have to change the noasserts
>>>> driver to *always* pass the option to the linker just in case we are
>>>> doing LTO.  Is this reasonable?
>>>> 
>>>> Also, I realized that passing `-mllvm -disable-llvm-verifier` to ld64
>>>> is redundant... so I'm thinking `-mllvm -disable-verify`.  Make
>>>> sense?
>>>> 
>>>> *sigh* Reasons to hate the driver interface again...
>>>> 
>>>> I guess this is ok. Could possibly add it to the existing terrible
>>> "enable this pass" interface on liblto as well.
>>> 
>>> The linker doesn't know whether clang was built with asserts, though.
>>> 
>>> We could just make it implicit: move the decision to libLTO itself.  Given
>>> that clang and libLTO.dylib are different executables anyway -- and you
>>> might be interposing an asserts libLTO.dylib to use with an installed clang
>>> -- maybe it's even better?
>>> 
>>> 
>> *nod* We could do that. Seems better than the alternative.
> 
> +1

Finally got back to this.  Done in r247729.

I didn't modify gold-plugin.cpp, as I don't have a good way to test it,
but someone else should be able to do it pretty easily.


More information about the llvm-dev mailing list