[llvm-dev] [OpenMP][AArch64][GlobalISel] AArch64 OMPT tests failing
David Greene via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 21 08:42:39 PST 2018
I opened bug 40131 and will provide assembly attachments as soon as I
can get to a machine that can upload them.
-David
Jonas Hahnfeld <hahnjo at hahnjo.de> writes:
> On 2018-12-21 16:43, David Greene wrote:
>> I took a look at the asm for control_tool.c. I'm not familiar with
>> OMPT so I
>> might have to get our OMP guys involved, but I think this is the
>> relevant piece
>> of code:
>>
>> 403648: 97fff472 bl 400810 <omp_control_tool at plt>
>> 40364c: d503201f nop
>> 403650: b9000fe0 str w0, [sp,#12]
>> 403654: 14000001 b 403658 <.omp_outlined.+0xa8>
>
> Could you post a bit more of context? It would be helpful to see
> what's the address of the generated label. This should be somewhere
> before the call to 'printf'.
>
>> This code is the same with and without GlobalISel.
>
> Hmm, does this mean it's also failing without GlobalISel? If not then
> there must be something different, it might just be somewhere else...
> In the above code, the last line is an unconditional branch to the
> next instruction. If I remember correctly, that was the issue we
> identified back then. Could you post the asm without GlobalISel for
> comparison?
>
>> Bug 36313 mentions that if the called routine returns a value, the
>> return
>> address will be off due to an added store. omp_control_tool does
>> indeed
>> return a value. Is this simply a matter of fixing the test?
>
> The test should already deal with this:
> https://github.com/llvm-mirror/openmp/blob/master/runtime/test/ompt/callback.h#L160. The
> NOP is always there, the store is related to functions that return a
> value (like omp_control_tool does).
>
> Thanks,
> Jonas
>
>>
>> -David
>>
>> ________________________________________
>> From: Openmp-dev <openmp-dev-bounces at lists.llvm.org> on behalf of
>> David Greene via Openmp-dev <openmp-dev at lists.llvm.org>
>> Sent: Friday, December 21, 2018 9:30:19 AM
>> To: Jonas Hahnfeld
>> Cc: llvm-dev at lists.llvm.org; aemerson at apple.com; Petr Pavlu;
>> openmp-dev at lists.llvm.org
>> Subject: Re: [Openmp-dev] [llvm-dev] [OpenMP][AArch64][GlobalISel]
>> AArch64 OMPT tests failing
>>
>> Curious. I removed -fno-experimental-isel and all of the tests
>> *except*
>> control_tool.c passed. I would have expected all of them to pass if
>> blockaddress works.
>>
>> I'll try to look at some asm and see what's going on.
>>
>> -David
>>
>> Jonas Hahnfeld <hahnjo at hahnjo.de> writes:
>>
>>> Hi David,
>>>
>>> I was the one who originally added the flag to fix failures related to
>>> GlobalISel. This was because first versions of GlobalISel didn't know
>>> how to select 'blockaddress', but this should have been fixed (see
>>> https://bugs.llvm.org/show_bug.cgi?id=36390) and available in both 7.0
>>> and trunk.
>>> There has been some discussion prior to that in
>>> https://bugs.llvm.org/show_bug.cgi?id=36313, maybe you could look into
>>> what's still wrong on AArch64?
>>>
>>> Cheers,
>>> Jonas
>>>
>>> On 2018-12-20 22:34, David Greene via llvm-dev wrote:
>>>> We're seeing OMPT tests fail on AArch64:
>>>>
>>>> libomp :: ompt/misc/control_tool.c
>>>> libomp :: ompt/synchronization/master.c
>>>> libomp :: ompt/synchronization/taskwait.c
>>>>
>>>> The failure mode is similar for all of them:
>>>>
>>>> openmp/runtime/test/ompt/misc/control_tool.c:26:17: error:
>>>> CHECK-NEXT:
>>>> expected string not found in input
>>>> // CHECK-NEXT: {{^}}[[MASTER_ID]]:
>>>> current_address={{.*}}[[RETURN_ADDRESS]]
>>>> ^
>>>> <stdin>:9:1: note: scanning from here
>>>> 281474976710657: current_address=0x402cf4 or 0x402cf0
>>>> ^
>>>> <stdin>:9:1: note: with variable "MASTER_ID" equal to
>>>> "281474976710657"
>>>> 281474976710657: current_address=0x402cf4 or 0x402cf0
>>>> ^
>>>> <stdin>:9:1: note: with variable "RETURN_ADDRESS" equal to "0x402cec"
>>>> 281474976710657: current_address=0x402cf4 or 0x402cf0
>>>> ^
>>>> <stdin>:9:13: note: possible intended match here
>>>> 281474976710657: current_address=0x402cf4 or 0x402cf0
>>>> ^
>>>>
>>>> I bisected the control_tool.c failure to:
>>>>
>>>> 3834f852008a82e361d325ec7b1c3fee0dc783c3 is the first bad commit
>>>> commit 3834f852008a82e361d325ec7b1c3fee0dc783c3
>>>> Author: Petr Pavlu <petr.pavlu at arm.com>
>>>> Date: Thu Nov 29 12:56:32 2018 +0000
>>>>
>>>> [GlobalISel] Make EnableGlobalISel always set when GISel is
>>>> enabled
>>>>
>>>> Change meaning of TargetOptions::EnableGlobalISel. The flag was
>>>> previously set only when a target switched on GlobalISel but it
>>>> is now
>>>> always set when the GlobalISel pipeline is enabled. This makes
>>>> the flag
>>>> consistent with TargetOptions::EnableFastISel and allows its
>>>> use in
>>>> other parts of the compiler to determine when GlobalISel is
>>>> enabled.
>>>>
>>>> The EnableGlobalISel flag had previouly only one use in
>>>> TargetPassConfig::isGlobalISelAbortEnabled(). The method used
>>>> its value
>>>> to determine if GlobalISel was enabled by a target and returned
>>>> false in
>>>> such a case. To preserve the current behaviour, a new flag
>>>> TargetOptions::GlobalISelAbort is introduced to separately
>>>> record the
>>>> abort behaviour.
>>>>
>>>> Differential Revision: https://reviews.llvm.org/D54518>>>>
>>>> git-svn-id:
>>>> https://llvm.org/svn/llvm-project/llvm/trunk@347861>>>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>>
>>>> Is it possible this commit changed the behavior of clang's
>>>> -fno-experimental-isel? The OpenMP tests use that flag.
>>>>
>>>> -David
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
More information about the llvm-dev
mailing list