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

Eli Friedman via llvm-dev
Fri, 27 Sep 2019 01:16:38 -0000

> -----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?  And you *only* need to
rewrite branches this way; never anything else, because other instructions
don't need relaxation?

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.

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

-Eli