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

[Eric Christopher via llvm-dev]

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.


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


Ah, using the C++ interface to handle everything and not using libLTO at
all.

He can speak more to this though.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150903/8532831b/attachment.html>