[llvm-dev] [RFC] Propeller: A frame work for Post Link Optimizations

Mon Sep 30 12:31:14 PDT 2019

On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com>
wrote:

> On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam <tmsriram at google.com>
> wrote:
> >
> >
> >
> > On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com>
> wrote:
> >>
> >> On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> >
> >> > On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com>
> wrote:
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: Sriraman Tallam <tmsriram at google.com>
> >> > > > Sent: Friday, September 27, 2019 9:43 AM
> >> > > > To: Eli Friedman <efriedma at quicinc.com>
> >> > > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <
> llvm-dev at lists.llvm.org>
> >> > > > Subject: [EXT] Re: [llvm-dev] [RFC] Propeller: A frame work for
> Post Link
> >> > > > Optimizations
> >> > > >
> >> > > > >
> >> > > > > > > Why are you proposing to add a bunch of options to clang to
> manipulate
> >> > > > LLVM
> >> > > > > > code generation, given none of those options are actually
> used for Propeller
> >> > > > > > workflows?
> >> > > > > >
> >> > > > > > Where do you suggest labelling and section options should
> exist?  We
> >> > > > > > looked at  basic block sections to be similar to function
> sections in
> >> > > > > > terms of option handling?
> >> > > > >
> >> > > > > Generating bitcode with/without propeller doesn't actually
> affect the
> >> > > > generated bitcode, right?  So you could say that Propeller is
> enabled with "-Wl,--
> >> > > > enable-propeller", and not change clang at all.  I'm not a fan of
> adding options
> >> > > > just because we can.  If basic block sections are only used as a
> sort of secret
> >> > > > handshake between the propeller compiler and the propeller
> linker, we can
> >> > > > change that interface later, if we want; if we expose it as a
> clang option, we're
> >> > > > committing to making basic block sections continue to work the
> same way until
> >> > > > the end of time.
> >> > > >
> >> > > > The generated MIR code is slightly different as the later passes
> have
> >> > > > more CFI instructions, basic block labels and extra direct jumps
> which
> >> > > > would have been fall throughs otherwise.  So, some llvm option is
> >> > > > needed.
> >> > >
> >> > > At link (LTO codegen) time, yes.  But clang's bitcode generation
> doesn't change; only LTO code generation in lld changes.
> >> >
> >> > I see what you mean here.
> >> >
> >> > >
> >> > > > I envisioned that basic block sections could also be useful on
> its own
> >> > > > outside of propeller.   Hence, we made it like function-sections
> with
> >> > > > a separate option -fbasicblock-sections.  The propeller option is
> an
> >> > > > umbrella option to make it easy to invoke Propeller.
> >> > >
> >> > > I don't think this is really true.  Basic block labels means
> "insert labels that are useful for propeller profiling", and basic block
> sections means "split the function into multiple chunks that are convenient
> for propeller optimization".  So it's really only useful for propeller-like
> workflows.  And I'd be concerned that future changes to propeller could
> affect the behavior of these options in the future, if the behavior isn't
> specified in some rigorous way.
> >> >
> >> > The idea of basic block sections was seeded by Rui Ueyama.  When basic
> >> > block sections was originally looked at, Propeller was not designed.
> >> > We looked at basic block sections as finer granularity than function
> >> > sections.  Section prefix based code layout where you just create
> >> > smaller code sections and let the linker do what it does today would
> >> > have much better results with basic block sections.  Symbol ordering
> >> > file with basic block sections to do random orderings can be done
> >> > without invoking Propeller.  Function sections has found uses after it
> >> > was invented like Identical Code Folding.
> >> >
> >>
> >> I'm not sure that function sections are entirely an apt comparison
> >> here for a few reasons:
> >>
> >>  - function sections mostly gave an easy way to do ICF - using MIR or
> >> LLVM IR are also fairly effective means as is just using the linker to
> >
> >
> > I did not mean to suggest we should do folding with basic block sections
> and I am aware of the issues, though I am not ruling out the possibility.
> We had briefly brainstormed this.
> >
> > AFAICT, Function Sections was not invented to do ICF.  Function sections
> was used for linker garbage collection and global code layout and when we
> first worked on ICF for gold much later, we found function sections to be
> useful without which it would have been much  harder.
> >
>
> They're both in the same arena.
>
> >
> >>
> >> compare bytes. Using function sections can still run into language
> >> specific problems as well, hence why icf=safe vs icf=all. Though pcc's
> >
> >
> > Agreed, and I would like to humbly suggest that I added those options to
> gold originally and am aware of that.
>
> Of course, but context is helpful for discussion and for others in the
> future understanding the discussion.
>
> >
> >>
> >> recent work helps out a little bit via significant address
> >> determination in the front end
> >>  - order files and other similar mechanisms work based on externally
> >> visible symbols and are fairly straightforward to use in an ABI safe
> >> way (no function -> function fallthrough for example)
> >>  - basic block sections can run into the multiple entry point problems
> >> depending on how they're laid out as well as other ABI and visibility
> >> issues
> >>
> >>
> >> This can likely be done safely, but there are definitely some concerns
> >> here with how you want to enable the use of basic block
> >> labels/sections.
> >
> >
> > I would like to expose basic block sections independently and let me
> talk more about one more effort we are trying to do.  Independent of
> Propeller, we are looking at a machine learning based approach to do code
> layout at link time.  I won't go into the details of the features but
> having basic block sections allows us to naturally feed the native object
> files into a black box that would try several different reorderings of the
> sections and learn a model.  We looked at basic block sections as the
> building block on top of which Propeller was built.  I don't think it would
> be the only application, just my opinion.
> >
>
> Again a question of "why at the object level rather than a low level
> IR" seems like something we should really explore the tradeoffs for at
> more length.
>

This is so that we can do inter-procedural basic block ordering.  Doing
this at link time with all the basic blocks exposes a lot more
inter-procedural ordering opportunities.  At a low-level IR, we are still
limited to intra-module basic block reordering.

Thanks
Sri

>
> -eric
>
> > Thanks
> > Sri
> >
> >
> >
> >
> >>
> >>
> >> -eric
> >>
> >>
> >> > >
> >> > > In any case, if we're adding flags to clang other than "enable
> propeller", I think we should have a separate thread on cfe-dev to discuss
> them. We don't expose every possible LLVM optimization and code generation
> option through clang. Users have a strong expectation of stability for
> clang options, and that means we need to evaluate each new option
> carefully, to decide whether it's something we really want to support
> indefinitely.
> >> >
> >> > Understood.
> >> >
> >> > Thanks
> >> > Sri
> >> >
> >> > >
> >> > > -Eli
> >> > _______________________________________________
> >> > LLVM Developers mailing list
> >> > llvm-dev at lists.llvm.org
> >> > https://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/20190930/bcf3af9a/attachment.html>