<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 13, 2018 at 2:17 PM Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Apr 23, 2018, at 1:24 PM, Friedman, Eli via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_4889193025859593352Apple-interchange-newline"><div>
<div bgcolor="#FFFFFF">
<div class="gmail-m_4889193025859593352moz-cite-prefix">On 4/20/2018 7:06 PM, Jessica Paquette
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<span style="font-family:HelveticaNeue">We perform
regular testing to ensure the outliner produces correct AArch64
code at -Oz. Tests include the LLVM test suite and standard
external test suites such as SPEC. All tests compile and
execute. We've also been making sure that the outliner produces
debuggable code. Users are still guaranteed to have sane
backtraces in the presence of outlined functions.</span><br style="font-family:HelveticaNeue">
<br style="font-family:HelveticaNeue">
<span style="font-family:HelveticaNeue">Added exposure
to various programs would help the outlining algorithm mature
further. This, in turn, will help the overall outlining project.
For example, there have been a few discussions on implementing
an IR-level outlining pass [3, 4]. Ultimately, the goal is to
create a shared outlining interface. This interface would allow
the outliner to exist at any level of representation [4]. The
general outlining algorithm will be part of the shared
interface. Thus, in the spirit of incremental improvement, it
makes sense to begin "stress-testing" it sooner than later.</span><br style="font-family:HelveticaNeue">
</blockquote>
<br>
I just tried some tests, and I'm seeing a bunch of failures on SPEC
at -O3; looks like mostly crashes at runtime. I can try to reduce
a testcase if you need it.<br>
<br>
<blockquote type="cite"><br style="font-family:HelveticaNeue">
<font face="HelveticaNeue">There are a few patches
necessary to facilitate this. They are available in the patches
section of this email. I’ll summarize what they do here for the
sake of discussion though.</font><br style="font-family:HelveticaNeue">
<br style="font-family:HelveticaNeue">
<span style="font-family:HelveticaNeue">The first patch
is one that teaches the backend about size optimization levels.
This is comparable to what's done in the inliner. Today, the
only way to tell if something is optimizing for size is by
looking at function attributes. This is fine for function
passes, but insufficient for module passes like the
MachineOutliner. The function attribute approach forces the
outliner to iterate over every function in the module before
deciding to take action. If -Oz isn't passed in, then the
outliner will not find any functions worth outlining from. This
would incur unnecessary compile-time overhead. Thus, we decided
the best course of action is to teach the backend about size
options.</span></blockquote>
<br>
I don't think this is really the right approach. With LTO, you can
have a mix of functions, some of which are minsize, and some of
which are not. Or with profile info, we might want to outline only
cold code (I guess this isn't implemented yet, but potentially
future work). Tying whether we run the outliner to a command-line
flag restricts the possible uses; either the entire module gets
outlining, or none of it does.<br></div></div></blockquote><div><br></div><div>Just to give some alternative view on this (currently going through the patches and wondering if things really have to be that complicated...):</div><div><br></div><div>- O0-O3 are handled by adding more/less passes into the pass pipeline and thereby enabling/disabling optimizations.</div><div>- When LTOing (mostly) the O0-O3 of the last LTO/linking step is what counts AFAIK.</div><div>- We probably want to have smarted behavior when mixing compilation untis with different optlevels, but we don't have one today.</div><div>- So why do we start creating a local solution for mixing -Os with non-Os code and the outliner here?</div></div></div></blockquote><div><br></div><div>Actually in LTO, as far as I know, we already honor function attributes from different module when mixing O0, O1/O2/O3, Os, and Oz. Function compiled with O0 would get an attribute that get them to not be optimized.</div><div>Having the outliner *not* honor the function attributes would be a departure from the usual behavior, I believe.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>