llvm dev - Aug 2015 - RFC: LTO should use -disable-llvm-verifier

On Mon, Aug 31, 2015 at 9:53 AM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
> Having it off by default makes sense to me. We just need an easy way of
> enabling it from the clang driver.
>
Not sure I follow? Generally LTO inputs are going to be "user
provided" (in
the sense that they're not produced immediately prior by the same process -
or you'd have just produced a single Module in the first place, I would
imagine) so changing the default still seems problematic in the sense of
allowing 'unbounded' input without verification...

> On Aug 29, 2015 6:04 PM, "Duncan P. N. Exon Smith via llvm-dev"
<
> llvm-dev at lists.llvm.org> wrote:
>
>> The verifier takes ~5% of link time when using LTO.  I think we
>> should add a `-disable-llvm-verifier` option to the LTO plugins, and
>> change the clang driver to pass the option through in release builds.
>> In asserts builds, the clang driver would not pass the option.
>>
>> This would match the way the driver passes -disable-llvm-verifier to
>> -cc1.
>>
>> Everyone on board?
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> 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/20150831/2a43725e/attachment.html>

> Not sure I follow? Generally LTO inputs are going to be "user
provided"
(in the sense that they're not produced immediately prior by the same
process - or you'd have just produced a single Module in the first place, I
would imagine) so changing the default still seems problematic in the sense
of allowing 'unbounded' input without verification...

The common case is for the bitcode to be generated by a paired clang. Even
when it is an old bitcode compiled module, the Module itself is created by
the bitcode reader.

Cheers, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150831/283aab05/attachment.html>

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
>
> > Not sure I follow? Generally LTO inputs are going to be "user
provided"
> (in the sense that they're not produced immediately prior by the same
> process - or you'd have just produced a single Module in the first
place, I
> would imagine) so changing the default still seems problematic in the sense
> of allowing 'unbounded' input without verification...
>
> The common case is for the bitcode to be generated by a paired clang. Even
> when it is an old bitcode compiled module, the Module itself is created by
> the bitcode reader.
>
Sure, but it is not uncommon to LTO with old bitcode. We all know it's
pretty easy to crash LLVM with bad bitcode or bad IR. These interfaces are
not thoroughly tested.

I think verifying the result of the bitcode reader by default during LTO is
probably the right thing for the foreseeable future. It's the only thing
that has any hope of telling the user something useful when things go wrong.

I'd like it if we spent a little effort understanding why it's slow
before
flipping it off. Maybe the verifier is running multiple times, instead of
after deserialization. We shouldn't need that in release builds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150831/9434748a/attachment.html>