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

On 13 Nov 2017, at 18:26, Quentin Colombet <qcolombet at
apple.com<mailto:qcolombet at apple.com>> wrote:

Hi Kristof,


On Nov 13, 2017, at 9:10 AM, Kristof Beyls <Kristof.Beyls at
arm.com<mailto:Kristof.Beyls at arm.com>> wrote:

Hi Quentin,

My only remaining concern is around ABI compatibility.
The following commit seems to indicate that in the previous round of evaluation,
we didn’t find an existing ABI compatibility issue:
http://llvm.org/viewvc/llvm-project?view=revision&revision=311388.
I haven’t looked into the details of this issue - so maybe I’m worried over
nothing?

No, you’re right. The problem with ABI is if you are consistently wrong, then
you won’t notice :).


I’m wondering if since then on your side you did any testing around ABI
compatibility?
E.g. building software where you semi-randomly build some functions through
GlobalISel and some functions through DAGISel?

Justin will look into that. Clang has utility script for that utils/ABITest.

Given we will only be able to check iOS ABI, you may want to follow the same
kind of validation on your side.

I let you sync up with Justin for the method.

Thanks Quentin & Justin!
I had a brief look at utils/ABITest. It seems a bit light on documentation on
how to best run the test.
I’m happy to try and run it on linux if you can share some info on the best way
to run that test, Justin?

Thanks!

Kristof

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

Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> On 13 Nov 2017, at 18:26, Quentin Colombet <qcolombet at apple.com>
wrote:
>> Hi Kristof,
>>
>> On Nov 13, 2017, at 9:10 AM, Kristof Beyls <Kristof.Beyls at
arm.com> wrote:
>>> Hi Quentin,
>>>
>>> My only remaining concern is around ABI compatibility.
>>> The following commit seems to indicate that in the previous round
of
>>> evaluation, we didn’t find an existing ABI compatibility issue:
>>>
http://llvm.org/viewvc/llvm-project?view=revision&revision=311388.
>>> I haven’t looked into the details of this issue - so maybe I’m
worried
>>> over nothing?
>>
>> No, you’re right. The problem with ABI is if you are consistently
wrong,
>> then you won’t notice :).
>>
>>> I’m wondering if since then on your side you did any testing around
>>> ABI compatibility?
>>> E.g. building software where you semi-randomly build some functions
>>> through GlobalISel and some functions through DAGISel?
>>
>> Justin will look into that. Clang has utility script for that utils/
>> ABITest.
>>
>> Given we will only be able to check iOS ABI, you may want to follow the
>> same kind of validation on your side.
>>
>> I let you sync up with Justin for the method.
>
> Thanks Quentin & Justin!
> I had a brief look at utils/ABITest. It seems a bit light on documentation
on
> how to best run the test.
A bit light is putting it lightly ;)
> I’m happy to try and run it on linux if you can share some info on the best
> way to run that test, Justin?
I played around with utils/ABITest a bit and I managed to get it to run
with some minor changes, though it is not at all obvious how this thing
works.

The main thing is to change from trying to compare gcc to clang to
compare clang and clang -mllvm -global-isel instead:

diff --git a/utils/ABITest/Makefile.test.common
b/utils/ABITest/Makefile.test.common
index 3c208adf0c..419d7cfab1 100644
--- a/utils/ABITest/Makefile.test.common
+++ b/utils/ABITest/Makefile.test.common
@@ -11,13 +11,14 @@ TESTARGS := --no-unsigned --no-vector --no-complex --no-bool
 COUNT := 1
 TIMEOUT := 5

-CFLAGS := -std=gnu99
+CFLAGS := -std=gnu99 -target arm64-apple-ios

-X_COMPILER := gcc
-X_LL_CFLAGS := -emit-llvm -S
-Y_COMPILER := clang
-Y_LL_CFLAGS := -emit-llvm -S
-CC := gcc
+CC := ${HOME}/build/llvm/bin/clang
+X_COMPILER := ${CC}
+Y_COMPILER := ${CC}
+
+X_CFLAGS :+Y_CFLAGS := -mllvm -global-isel

 ###

I also made a change to the "temps/test.%.out" target to copy the
binary
onto a device before trying to run it, since I was cross compiling, and
removed the 32-bit cases from build-and-summarize-all.sh since we're
only dealing with AArch64 here.

To see if it works, `cd` into one of the test directories (like
single-args-64) and run `make VERBOSE=1 test.0.report`. If it finds a
bug make will fail with something like "TEST 0: temps/test.0.yy.diff
failed".

Then, once things work, you can run ./build-and-summarize-all.sh 100
(or any number you like) from the ABITest directory and it will tell
you if it finds anything.

Justin Bogner <mail at justinbogner.com> writes:
> Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> On 13 Nov 2017, at 18:26, Quentin Colombet <qcolombet at
apple.com> wrote:
>>> Hi Kristof,
>>>
>>> On Nov 13, 2017, at 9:10 AM, Kristof Beyls <Kristof.Beyls at
arm.com> wrote:
>>>> Hi Quentin,
>>>>
>>>> My only remaining concern is around ABI compatibility.
>>>> The following commit seems to indicate that in the previous
round of
>>>> evaluation, we didn’t find an existing ABI compatibility issue:
>>>>
http://llvm.org/viewvc/llvm-project?view=revision&revision=311388.
>>>> I haven’t looked into the details of this issue - so maybe I’m
worried
>>>> over nothing?
>>>
>>> No, you’re right. The problem with ABI is if you are consistently
wrong,
>>> then you won’t notice :).
>>>
>>>> I’m wondering if since then on your side you did any testing
around
>>>> ABI compatibility?
>>>> E.g. building software where you semi-randomly build some
functions
>>>> through GlobalISel and some functions through DAGISel?
>>>
>>> Justin will look into that. Clang has utility script for that
utils/
>>> ABITest.
>>>
>>> Given we will only be able to check iOS ABI, you may want to follow
the
>>> same kind of validation on your side.
Looping back here, I generated and ran 1000000 test cases with the
ABITest utility and hit some fallbacks and an "invalid zero-sized
type"
assert that need looking at, but it didn't uncover any ABI issues.
>>> I let you sync up with Justin for the method.
>>
>> Thanks Quentin & Justin!
>> I had a brief look at utils/ABITest. It seems a bit light on
documentation on
>> how to best run the test.
>
> A bit light is putting it lightly ;)
>
>> I’m happy to try and run it on linux if you can share some info on the
best
>> way to run that test, Justin?
>
> I played around with utils/ABITest a bit and I managed to get it to run
> with some minor changes, though it is not at all obvious how this thing
> works.
>
> The main thing is to change from trying to compare gcc to clang to
> compare clang and clang -mllvm -global-isel instead:
>
> diff --git a/utils/ABITest/Makefile.test.common
b/utils/ABITest/Makefile.test.common
> index 3c208adf0c..419d7cfab1 100644
> --- a/utils/ABITest/Makefile.test.common
> +++ b/utils/ABITest/Makefile.test.common
> @@ -11,13 +11,14 @@ TESTARGS := --no-unsigned --no-vector --no-complex
--no-bool
>  COUNT := 1
>  TIMEOUT := 5
>
> -CFLAGS := -std=gnu99
> +CFLAGS := -std=gnu99 -target arm64-apple-ios
>
> -X_COMPILER := gcc
> -X_LL_CFLAGS := -emit-llvm -S
> -Y_COMPILER := clang
> -Y_LL_CFLAGS := -emit-llvm -S
> -CC := gcc
> +CC := ${HOME}/build/llvm/bin/clang
> +X_COMPILER := ${CC}
> +Y_COMPILER := ${CC}
> +
> +X_CFLAGS :> +Y_CFLAGS := -mllvm -global-isel
>
>  ###
>
> I also made a change to the "temps/test.%.out" target to copy the
binary
> onto a device before trying to run it, since I was cross compiling, and
> removed the 32-bit cases from build-and-summarize-all.sh since we're
> only dealing with AArch64 here.
>
> To see if it works, `cd` into one of the test directories (like
> single-args-64) and run `make VERBOSE=1 test.0.report`. If it finds a
> bug make will fail with something like "TEST 0: temps/test.0.yy.diff
> failed".
>
> Then, once things work, you can run ./build-and-summarize-all.sh 100
> (or any number you like) from the ABITest directory and it will tell
> you if it finds anything.