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

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

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>

On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher
wrote:
> 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.
+1
> > > 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.
The C++ interface is much more convenient for a C++ program to use, but
clients need to revlock themselves to LLVM in order to use it.

In theory the same does not apply to libLTO, but we do end up changing it
occasionally to add new APIs which ld64 promptly starts using, so it isn't
clear how much ld64 gains by relying on libLTO, or whether the burden on
in-tree clients is worth it (there are certainly a number of internal APIs
that are more clumsy as a result of needing to support libLTO's API; see
e.g. llvm::splitCodeGen's return value).

Thanks,
-- 
Peter