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

Sriraman Tallam via llvm-dev
Mon, 30 Sep 2019 20:33:50 -0000

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

> On Mon, Sep 30, 2019 at 12:31 PM Sriraman Tallam <tmsriram at
google.com>
> wrote:
> >
> >
> >
> > 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.
> >
>
> Seems like you could spend just as much work and reliability on making
> MIR/late stage LTO compilation handle this for you?
>

Full LTO yes, Thin LTO ... no.  We want this to be scalable and ThinLTO is
what we are more interested in.

Thanks
Sri


>
> -eric
>
> > 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/842008c1/attachment.html>