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

[Sriraman Tallam via llvm-dev]

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
> compare bytes. Using function sections can still run into language
> specific problems as well, hence why icf=safe vs icf=all. Though pcc's
> 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)
>

I missed this point.  Just to be clear, With the linker relaxation, a
simple order file of basic block symbols can be used to re-order basic
blocks in any manner. This can be done with the existing patches *now* and
we have used this extensively in our work to validate our layout decisions.


>  - 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.
>
> -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/20190928/0bac19f5/attachment.html>