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

[Matthias Braun via llvm-dev]

> 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?

- Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180713/da8503f6/attachment.html>