[llvm-dev] [RFC] Turn the MachineOutliner on by default in AArch64 under -Oz

[Mehdi AMINI via llvm-dev]

On Fri, Jul 13, 2018 at 2:17 PM Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Apr 23, 2018, at 1:24 PM, Friedman, Eli via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On 4/20/2018 7:06 PM, Jessica Paquette via llvm-dev wrote:
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
>
> Just to give some alternative view on this (currently going through the
> patches and wondering if things really have to be that complicated...):
>
> - O0-O3 are handled by adding more/less passes into the pass pipeline and
> thereby enabling/disabling optimizations.
> - When LTOing (mostly) the O0-O3 of the last LTO/linking step is what
> counts AFAIK.
> - We probably want to have smarted behavior when mixing compilation untis
> with different optlevels, but we don't have one today.
> - So why do we start creating a local solution for mixing -Os with non-Os
> code and the outliner here?
>

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.
Having the outliner *not* honor the function attributes would be a
departure from the usual behavior, I believe.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/97a96157/attachment-0001.html>