llvm dev - Mar 2017 - [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!

Hi,

GlobalISel, the SelectionDAG replacement, has come a long way since initially
discussed on the mailing list and its last discussion at the EuroLLVM BoF
(https://etherpad.net/p/GlobalISel <https://etherpad.net/p/GlobalISel>).
We believe we are close to the point of enabling it by default on AArch64 at O0.
We now would like to enlist your help to get there.


*** Quick Status ***

On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard
benchmarks and unit tests. In about 5% of all functions GlobalIsel falls back to
SDIsel.
(Kristof Beyls would have the linux numbers.)
The self host compiler correctly builds and runs the LLVM test suite in O0.


*** We Need Your Help ***

Please try GlobalISel for AArch64 at O0 (preferably O0 g) and file PR for:
- Performance problems (compile time, runtime, code size)
- Miscompile
- Crashers
- Poor debug information
- etc.

There is a component GlobalISel in llvm.org/bugs <http://llvm.org/bugs>
for that.

GlobalISel cannot handle some inputs (e.g., some vector construction), but it
falls back to SDISel when it hits such cases. We are also interested to know
whether or not GlobalISel fallback on your favorite workloads and why (see next
section for the actual options to run). So please file PRs for that too.

As always, patches are welcome!


*** Concretely What Do I Run ***

Please test your favorite workload/scenario on AArch64 at O0 using one of the
following additional category of options:
Recommended: (-llvm) -global-isel (-mllvm) -global-isel-abort=2
OkToFallBack:: (-llvm) -global-isel (-mllvm) -global-isel-abort=0
AbortOnFallBack: (-llvm) -global-isel

The Recommended way will issue a warning if it falls back to SelectionDAG, the
OkToFallBack will silently fallback to SDISel if it needs to, and the
AbortOnFallBack will kill the compiler if GlobalISel cannot handle the input
completely.


*** What Is Next? ***

We would like to turn on GobalISel by default in the next couple of weeks.
Please help identify any critical issue that needs to be resolved before that
can happen. We expect that minor hiccups and outliers in any metrics can be
fixed quickly, but are worried about harmful run-time (miscompile) or
compile-time crashes.


Many thanks,
-Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170329/25f66324/attachment.html>

On 30 March 2017 at 00:27, Quentin Colombet <qcolombet at apple.com>
wrote:
> On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard
> benchmarks and unit tests. In about 5% of all functions GlobalIsel falls
> back to SDIsel.
> (Kristof Beyls would have the linux numbers.)
> The self host compiler correctly builds and runs the LLVM test suite in O0.
Having done no tests at all on my side, I think we need to have
similar numbers on Linux to be able to flip across the board.

I don't want to flip it only for Darwin and not Linux, as that will
fragment the effort too much.

I'll check with Diana and Kristof to know what's the best way forward,
but it should be reasonably quick.

cheers,
--renato

Hi Renato,

If Kristof is busy I can make runs on AArch64 Linux (Cortex-A53 and Cortex-57).

Thanks,
Evgeny Astigeevich
Senior Compiler Engineer
Compilation Tools
ARM
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Renato Golin via llvm-dev
> Sent: Thursday, March 30, 2017 9:54 AM
> To: Quentin Colombet
> Cc: llvm-dev; Justin Bogner; Ahmed Bougacha; Aditya Nandakumar
> Subject: Re: [llvm-dev] [GlobalISel][AArch64] Toward flipping the switch
for
> O0: Please give it a try!
> 
> On 30 March 2017 at 00:27, Quentin Colombet <qcolombet at apple.com>
> wrote:
> > On iOS we are at 100% pass rate in 00 g for the LLVM test suite,
> > standard benchmarks and unit tests. In about 5% of all functions
> > GlobalIsel falls back to SDIsel.
> > (Kristof Beyls would have the linux numbers.) The self host compiler
> > correctly builds and runs the LLVM test suite in O0.
> 
> Having done no tests at all on my side, I think we need to have similar
> numbers on Linux to be able to flip across the board.
> 
> I don't want to flip it only for Darwin and not Linux, as that will
fragment the
> effort too much.
> 
> I'll check with Diana and Kristof to know what's the best way
forward, but it
> should be reasonably quick.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I've kicked off a run to compare "-O0 -g" versus "-O0 -g
-mllvm -global-isel -mllvm -global-isel-abort=2".
I've selected the test-suite (albeit a version which is a couple of months
old now) and a few short-running proprietary benchmarks to get data back quickly
for an initial feel of where things are.
This was running on Cortex-A57 AArch64 Linux.

I saw one assertion failure in GlobalISel, see
http://bugs.llvm.org/show_bug.cgi?id=32471. This is in a program compiled at -O2
(my out-dated test-suite still overrides -O0 and instead uses -O for that
program). The root cause of the failure seems to be due to LowLevelType not
supporting vectors of pointers. I think this demonstrates that for correctness,
we should be trying to test more than -O0, or even more than just LLVM-IR
produced by clang, as other front-ends could run into this even at -O0.

Due to this assertion failure and the infrastructure I used, the numbers below
do not include test-suite/MultiSource/Benchmarks results.

On the non-correctness aspects, LNT tells me that:
- The programs that report execution time, on geomean are about 17% slower.
- The programs that report scores, on geomean are about 21% slower.
- Code size is up on geomean about 11%.
I'm afraid I don't have compile time numbers, nor any feel for debug
info quality.

I'll need quite a bit more time to dig into the details to come up with
something actionable, although the fact that LowLevelType doesn't support
vectors of pointers is already actionable.
Nevertheless, I thought to share what I see as is, to see if others see similar
results so far.

I thought Diana was going to look into fallback rate on the test-suite on
AArch64 linux?

Thanks,

Kristof

On 30 Mar 2017, at 10:54, Renato Golin <renato.golin at
linaro.org<mailto:renato.golin at linaro.org>> wrote:

On 30 March 2017 at 00:27, Quentin Colombet <qcolombet at
apple.com<mailto:qcolombet at apple.com>> wrote:
On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard
benchmarks and unit tests. In about 5% of all functions GlobalIsel falls
back to SDIsel.
(Kristof Beyls would have the linux numbers.)
The self host compiler correctly builds and runs the LLVM test suite in O0.

Having done no tests at all on my side, I think we need to have
similar numbers on Linux to be able to flip across the board.

I don't want to flip it only for Darwin and not Linux, as that will
fragment the effort too much.

I'll check with Diana and Kristof to know what's the best way forward,
but it should be reasonably quick.

cheers,
--renato

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

Would this completely replace FastISel (on AArch64) then? So that we have to
look for bugs only in GlobalISel and SelectionDAG?

- Matthias
> On Mar 29, 2017, at 4:27 PM, Quentin Colombet via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi,
> 
> GlobalISel, the SelectionDAG replacement, has come a long way since
initially discussed on the mailing list and its last discussion at the EuroLLVM
BoF (https://etherpad.net/p/GlobalISel
<https://etherpad.net/p/GlobalISel>).
> We believe we are close to the point of enabling it by default on AArch64
at O0. We now would like to enlist your help to get there.
> 
> 
> *** Quick Status ***
> 
> On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard
benchmarks and unit tests. In about 5% of all functions GlobalIsel falls back to
SDIsel.
> (Kristof Beyls would have the linux numbers.)
> The self host compiler correctly builds and runs the LLVM test suite in O0.
> 
> 
> *** We Need Your Help ***
> 
> Please try GlobalISel for AArch64 at O0 (preferably O0 g) and file PR for:
> - Performance problems (compile time, runtime, code size)
> - Miscompile
> - Crashers
> - Poor debug information
> - etc.
> 
> There is a component GlobalISel in llvm.org/bugs
<http://llvm.org/bugs> for that.
> 
> GlobalISel cannot handle some inputs (e.g., some vector construction), but
it falls back to SDISel when it hits such cases. We are also interested to know
whether or not GlobalISel fallback on your favorite workloads and why (see next
section for the actual options to run). So please file PRs for that too.
> 
> As always, patches are welcome!
> 
> 
> *** Concretely What Do I Run ***
> 
> Please test your favorite workload/scenario on AArch64 at O0 using one of
the following additional category of options:
> Recommended: (-llvm) -global-isel (-mllvm) -global-isel-abort=2
> OkToFallBack:: (-llvm) -global-isel (-mllvm) -global-isel-abort=0
> AbortOnFallBack: (-llvm) -global-isel
> 
> The Recommended way will issue a warning if it falls back to SelectionDAG,
the OkToFallBack will silently fallback to SDISel if it needs to, and the
AbortOnFallBack will kill the compiler if GlobalISel cannot handle the input
completely.
> 
> 
> *** What Is Next? ***
> 
> We would like to turn on GobalISel by default in the next couple of weeks.
Please help identify any critical issue that needs to be resolved before that
can happen. We expect that minor hiccups and outliers in any metrics can be
fixed quickly, but are worried about harmful run-time (miscompile) or
compile-time crashes.
> 
> 
> Many thanks,
> -Quentin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170404/e3e81628/attachment.html>