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

[Eli Friedman via llvm-dev]

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