<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 24, 2021 at 11:56 AM Roman Lebedev via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</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">lebedev.ri added a comment.<br>
<br>
In D101229#2714853 <<a href="https://reviews.llvm.org/D101229#2714853" rel="noreferrer" target="_blank">https://reviews.llvm.org/D101229#2714853</a>>, @davidxl wrote:<br>
<br>
> Changing the default threshold needs lots of benchmarking.<br>
<br>
<br>
<br>
> For this particular case, IMO the better way is to enhance inline cost<br>
> analysis to give callsite more bonus if it enables SROA in call context.<br>
<br>
I have thought about that too, yes.<br>
<br>
> The analysis needs to be careful such that if there is another callsite<br>
> that blocks SROA, and that callsites can never be inlined, then the bonus<br>
> can not be applied.<br>
<br>
So when inlining call to `curr_callee(arg)` from `entry()`,<br>
and we've deduced that `arg` is an alloca within `entry()`,<br>
we need to run an analysis on `entry()`, and verify that the alloca<br>
is not used by anything that would prevent SROA, that's obvious to me.<br>
<br>
The caveat that is a little murky to me still, *how* specifically<br>
should we deal with the cases when the alloca is passed as an argument<br>
to some other callee? I don't suppose we want to actually recurse into it?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">I suppose a preparation step analysis is needed: For each SROA candidate (which does not have its address used in an intractable way) in the caller function, compute the list of call sites with its address passed in.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">After all callsites are considered for inlining, the rejected callsites can be re-examined again. Say we have callsite A and B rejected, but they are associated with SROA candidate X. If A and B both can be inlined by applying the bonus, then A and B will be inlined. </div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">Ideally, the analysis should recursively considering callsites in the callee, but the compile time cost can be too large. The downside of not considering them is that the additional inlinings (due to bonus) may not necessarily result in SROA to happen in the caller.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">David</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>
> David<br>
<br>
<br>
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D101229/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D101229/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D101229" rel="noreferrer" target="_blank">https://reviews.llvm.org/D101229</a><br>
<br>
</blockquote></div></div>