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

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>

On Mon, Sep 30, 2019 at 1:34 PM Sriraman Tallam <tmsriram at google.com>
wrote:
>
>
> 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.
>
As Sri said, we need to be able to use this for ThinLTO, and I'm not sure
how you would do whole program BB layout in ThinLTO which does the whole
program analysis much much earlier than MIR. Eric - did you have something
else in mind or were you talking about Full LTO?

Teresa

> 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
>>
>
-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190930/21024906/attachment.html>

I guess Eric means full program optimization/cross module optimization
using MIR.   This is in theory workable in full LTO style, but not in
ThinLTO style which works on summary data.  As we have discussed,
eliminating monolithic style optimization is the key design goal.

This was also briefly discussed in one of the previous replies I sent.
There are other benefits of doing this in linker such as handling prebuilt
libraries such as libc.

David


On Mon, Sep 30, 2019 at 1:39 PM Teresa Johnson <tejohnson at google.com>
wrote:
>
>
> On Mon, Sep 30, 2019 at 1:34 PM Sriraman Tallam <tmsriram at
google.com>
> wrote:
>
>>
>>
>> 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.
>>
>
> As Sri said, we need to be able to use this for ThinLTO, and I'm not
sure
> how you would do whole program BB layout in ThinLTO which does the whole
> program analysis much much earlier than MIR. Eric - did you have something
> else in mind or were you talking about Full LTO?
>
> Teresa
>
>
>> 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
>>>
>>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190930/011e1d2a/attachment.html>