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

[Sriraman Tallam via llvm-dev]

On Thu, Sep 26, 2019 at 6:16 PM Eli Friedman <efriedma at quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Sriraman Tallam <tmsriram at google.com>
> > Sent: Thursday, September 26, 2019 5:31 PM
> > 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
> >
> > For more details, We strongly considered this.  We could run something
> > like a thin link in thin lto figure out the global layout and hand out
> > the relevant  subsets of the global decision  to each module.  This
> > looked more complicated and the individual pieces from each module
> > should still be globally laid out again by the linker.  This
> > constraints us on what we can do for layout and also does not work
> > well with future optimizations like global alignment like David
> > pointed out.
>
> Basically, you need to do branch relaxation etc. in the linker because the layout isn't sufficiently finalized until then?

Yes, this is correct.  Relaxation is needed because the layout is not
finalized until link time.




And you *only* need to rewrite branches this way; never anything else,
because other instructions don't need relaxation?

I cannot think of any other instance where such relaxation is needed.

>
> On most targets, we do branch relaxation in the compiler, unlike x86 which does it in the assembler.  I guess we could teach the compiler to emit some specific "relaxed" pattern, and teach the linker to reverse it.  Might be a little tricky to handle certain odd cases well; currently, for example, on AArch64 we sometimes insert a cpsr clobber as part of relaxation.  I'm not really happy with having to reimplement that for every target, but if we're sure it's limited to branches, I guess it's okay.

Understood.

>
> > > 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.

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.

Thanks
Sri

>
> -Eli