llvm dev - Jun 2015 - [LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)

On 8 Jun 2015, at 21:08, Eric Christopher <echristo at gmail.com>
wrote:
> 
> I'd rather not have it be an llvm option at all. Just construct a
different set of passes...
> 
> This would also solve the problem of needing multiple sets of options to be
passed to the builder. It'd be a bit of a change (i.e. having clang do the
pass setup), but I think it'd be worth it to have clang be able to
explicitly say which passes it wants.
There’s some value in making it possible for clang and opt to run the same set
of passes.  It’s also nice to be able to provide libraries that can inject
passes at specific points in the optimisation sequence (this was one of the
design goals of PassManagerBuilder) without needing to modify every front end
that might use them.

David

On Mon, Jun 8, 2015 at 1:18 PM David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 8 Jun 2015, at 21:08, Eric Christopher <echristo at gmail.com>
wrote:
> >
> > I'd rather not have it be an llvm option at all. Just construct a
> different set of passes...
> >
> > This would also solve the problem of needing multiple sets of options
to
> be passed to the builder. It'd be a bit of a change (i.e. having clang
do
> the pass setup), but I think it'd be worth it to have clang be able to
> explicitly say which passes it wants.
>
> There’s some value in making it possible for clang and opt to run the same
> set of passes.  It’s also nice to be able to provide libraries that can
> inject passes at specific points in the optimisation sequence (this was one
> of the design goals of PassManagerBuilder) without needing to modify every
> front end that might use them.
>
There's some point to what you say... except out of tree users are already
not doing this (from what I've heard) and we're developing a lot of
users
even in tree that are going to need to come up with basically their own
pass pipelines. See the cuda work, etc here.

So we're basically talking about opt and clang, which makes it fairly easy
to keep up to date. We already have the injection machinery anyhow and
that's only used to for some very small things (printing). Mostly what we
need is the ability to use entirely different optimization pipelines for
different uses and that's sadly lacking this way unless we have a "this
is
the lto pipeline, the general C pipeline, the C++ pipeline, the cuda
pipeline, the gpu pipeline, the <insert other use> pipeline...".

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150608/736dc9de/attachment.html>

On 8 Jun 2015, at 21:26, Eric Christopher <echristo at gmail.com>
wrote:
> 
> We already have the injection machinery anyhow and that's only used to
for some very small things (printing)
For what it’s worth, the GNUstep Objective-C runtime ships with an LLVM library
that injects some optimisations that are specific to this Objective-C
implementation into the pass sequence.  It’s not very widely used though, mainly
because the lack of stability in the APIs (not to mention ABIs) for things that
passes need mean that it’s basically impossible to ship out-of-tree passes
unless you sync your release schedule with LLVMs.  This is a shame, as there are
a lot of other libraries that would benefit from having specific optimisations
for some of their common patterns (Qt springs to mind), but that’s a different
discussion.

David