<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>> wrote:<br>
> ><br>
> > > -----Original Message-----<br>
> > > From: Sriraman Tallam <<a href="mailto:tmsriram@google.com" target="_blank">tmsriram@google.com</a>><br>
> > > Sent: Friday, September 27, 2019 9:43 AM<br>
> > > To: Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>><br>
> > > Cc: Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> > > Subject: [EXT] Re: [llvm-dev] [RFC] Propeller: A frame work for Post Link<br>
> > > Optimizations<br>
> > ><br>
> > > ><br>
> > > > > > Why are you proposing to add a bunch of options to clang to manipulate<br>
> > > LLVM<br>
> > > > > code generation, given none of those options are actually used for Propeller<br>
> > > > > workflows?<br>
> > > > ><br>
> > > > > Where do you suggest labelling and section options should exist?  We<br>
> > > > > looked at  basic block sections to be similar to function sections in<br>
> > > > > terms of option handling?<br>
> > > ><br>
> > > > Generating bitcode with/without propeller doesn't actually affect the<br>
> > > generated bitcode, right?  So you could say that Propeller is enabled with "-Wl,--<br>
> > > enable-propeller", and not change clang at all.  I'm not a fan of adding options<br>
> > > just because we can.  If basic block sections are only used as a sort of secret<br>
> > > handshake between the propeller compiler and the propeller linker, we can<br>
> > > change that interface later, if we want; if we expose it as a clang option, we're<br>
> > > committing to making basic block sections continue to work the same way until<br>
> > > the end of time.<br>
> > ><br>
> > > The generated MIR code is slightly different as the later passes have<br>
> > > more CFI instructions, basic block labels and extra direct jumps which<br>
> > > would have been fall throughs otherwise.  So, some llvm option is<br>
> > > needed.<br>
> ><br>
> > At link (LTO codegen) time, yes.  But clang's bitcode generation doesn't change; only LTO code generation in lld changes.<br>
><br>
> I see what you mean here.<br>
><br>
> ><br>
> > > I envisioned that basic block sections could also be useful on its own<br>
> > > outside of propeller.   Hence, we made it like function-sections with<br>
> > > a separate option -fbasicblock-sections.  The propeller option is an<br>
> > > umbrella option to make it easy to invoke Propeller.<br>
> ><br>
> > 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.<br>
><br>
> The idea of basic block sections was seeded by Rui Ueyama.  When basic<br>
> block sections was originally looked at, Propeller was not designed.<br>
> We looked at basic block sections as finer granularity than function<br>
> sections.  Section prefix based code layout where you just create<br>
> smaller code sections and let the linker do what it does today would<br>
> have much better results with basic block sections.  Symbol ordering<br>
> file with basic block sections to do random orderings can be done<br>
> without invoking Propeller.  Function sections has found uses after it<br>
> was invented like Identical Code Folding.<br>
><br>
<br>
I'm not sure that function sections are entirely an apt comparison<br>
here for a few reasons:<br>
<br>
 - function sections mostly gave an easy way to do ICF - using MIR or<br>
LLVM IR are also fairly effective means as is just using the linker to<br>
compare bytes. Using function sections can still run into language<br>
specific problems as well, hence why icf=safe vs icf=all. Though pcc's<br>
recent work helps out a little bit via significant address<br>
determination in the front end<br>
 - order files and other similar mechanisms work based on externally<br>
visible symbols and are fairly straightforward to use in an ABI safe<br>
way (no function -> function fallthrough for example)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - basic block sections can run into the multiple entry point problems<br>
depending on how they're laid out as well as other ABI and visibility<br>
issues<br>
<br>
This can likely be done safely, but there are definitely some concerns<br>
here with how you want to enable the use of basic block<br>
labels/sections.<br>
<br>
-eric<br>
<br>
<br>
> ><br>
> > 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.<br>
><br>
> Understood.<br>
><br>
> Thanks<br>
> Sri<br>
><br>
> ><br>
> > -Eli<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>