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

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?

On Sat, Aug 29, 2015 at 03:03:50PM -0700, Duncan P. N. Exon Smith via llvm-dev
wrote:
> The verifier takes ~5% of link time when using LTO.
Why is it so slow?

Joerg

On Sat, Aug 29, 2015 at 5:42 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Sat, Aug 29, 2015 at 03:03:50PM -0700, Duncan P. N. Exon Smith via
> llvm-dev wrote:
> > The verifier takes ~5% of link time when using LTO.
>
> Why is it so slow?
>
I would guess it's because of the seer size of post-LTO bins.

>
> Joerg
> _______________________________________________
> 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/20150829/c454552c/attachment.html>

For cc1 we disable it for IR generated immediately by clang. We don't
disable it for IR or bitcode inouts provided by the user.

So I'd be a bit hesitant to disable it for lto because it is an
unrestricted input at lto time.

(But this is hardly my wheelhouse. So grain of salt and all)
On Aug 29, 2015 3: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150829/b12329f5/attachment.html>

Random thoughts.

- Could we implement lightweight verifier?
- Verifier can run in parallel in some cases.
- Any mechanism for credit emitted by same version of LLVM bitwriter, like
signature.

I think we should be formal in user inputs, too.

2015年8月30日(日) 9:59 David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org>:
> For cc1 we disable it for IR generated immediately by clang. We don't
> disable it for IR or bitcode inouts provided by the user.
>
> So I'd be a bit hesitant to disable it for lto because it is an
> unrestricted input at lto time.
>
> (But this is hardly my wheelhouse. So grain of salt and all)
> On Aug 29, 2015 3: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/20150830/c829aea5/attachment.html>

On Sat, Aug 29, 2015 at 3:03 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?
>
I would prefer to keep it on by default; in the cc1 case we know that the
input was immediately produced by clang (so we have a pretty high
confidence that it is correct), which is not the case in LTO.

The verifier should be pretty much the cheapest of all passes. If it is
taking 5%, then that means that we can be running a max of 20 passes, which
seems off (especially considering that some passes should be *enormously*
more expensive, like codegen). Is 5% a number you measured in a profiler or
an empirical difference when running with/without -disable-llvm-verifier?
Do you have a breakdown of where that 5% is coming from? Is the number
consistent across different programs (e.g. of different sizes)?

-- Sean Silva

> _______________________________________________
> 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/20150830/1ebd903e/attachment.html>

On Sun, Aug 30, 2015 at 1:03 PM, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Sat, Aug 29, 2015 at 3:03 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?
>>
>
> I would prefer to keep it on by default; in the cc1 case we know that the
> input was immediately produced by clang (so we have a pretty high
> confidence that it is correct), which is not the case in LTO.
>
> The verifier should be pretty much the cheapest of all passes. If it is
> taking 5%, then that means that we can be running a max of 20 passes,
>
Not quite sure I understand this conclusion - not all passes take similar
execution time (& especially not on larger inputs where they scale
differently, etc), right?

> which seems off (especially considering that some passes should be
> *enormously* more expensive, like codegen). Is 5% a number you measured in
> a profiler or an empirical difference when running with/without
> -disable-llvm-verifier? Do you have a breakdown of where that 5% is coming
> from? Is the number consistent across different programs (e.g. of different
> sizes)?
>
> -- Sean Silva
>
>
>> _______________________________________________
>> 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/ae32b462/attachment.html>

Having it off by default makes sense to me. We just need an easy way of
enabling it from the clang driver.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150831/62e7325b/attachment.html>

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>