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

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 3 18:03:59 PDT 2015


> I don't suppose ld64 could move to a model like we're talking about with
lld that pcc is working on?

FWIW I'm working on getting LLVM/Clang linking with lld on Darwin. I
haven't had a good look at the LTO interface yet, but hopefully I'll get to
it soon.

Cheers,
Lang.

On Mon, Aug 31, 2015 at 6:09 PM, Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
> I don't suppose ld64 could move to a model like we're talking about with
> lld that pcc is working on?
>
> -eric
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150903/cba65959/attachment.html>


More information about the llvm-dev mailing list