<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 1:16 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.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">> -----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></blockquote><div><br></div><div>After having spent more time on this, I think what you are suggesting is to impose this work-flow for Propeller always:</div><div><br></div><div><div>Step 1: generate labels binary</div><div><br></div><div>clang -emit-llvm -c -O2 foo.cc  bar.cc (generates optimized foo.bc and bar.bc)</div><div>./lld foo.bc bar.bc --basicblock-labels -o a.out.labels (generates labels binary)</div><div><br></div><div>Step 2: Profile into perf.data just like now</div><div><br></div><div>Step 3: Convert profiles just like now</div><div><br></div><div>Step 4: Re-optimize with propeller by invoking lld directly</div><div>./lld foo.bc bar.bc --basicblock-sections --profile=perf.propeller -o a.out<br></div><div><br></div><div>If this workflow is adopted we might be able to get away without clang options but I still think Step 1 could use a clang option to combine the 2 steps into one and may be one more option in Step 4 might be useful if we want the invocation to be via clang.<br></div><div><br></div><div>Notice how this work-flow is very similar to ThinLTO's, and even thinlto needs command-line options, -flto=thin, to break this down into the steps.</div><div><br></div><div>However, the issue with this work-flow imposes LTO like workflow on Propeller. Propeller is LTO agnostic and works even without LTO or regular FDO. The above does not support the simple workflows where you build each module with -O3 and then dump the native object files and link.  I think it would be beneficial to allow Propeller to be used everywhere by modifying the make files to adopt it rather than constrain the work flow. </div><div><br></div><div>Thanks</div><div>Sri</div><div><br style="color:rgb(0,0,0)"></div></div><div><br></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">
<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>
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>
-Eli<br>
</blockquote></div></div>