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

> 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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150901/4e518945/attachment.html>

> 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?
> I don't suppose ld64 could move to a model like we're talking about
with lld that pcc is working on?
What specifically?

> 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>