On 5/17/21 6:47 PM, Tobias Burnus wrote:
> On 17.05.21 17:49, Tom de Vries wrote:
>> [ Tobias, can you test this on volta ? ]
>
> Unfortunately, it does not seem to help. On a non-Volta system, it still
> works (run time 0.3s) but on a Volta system it fails after 1.5s (abort).
>
> Looking (with an editor) at nvptx-none/lib/mgomp/libgomp.a, I still see
> @ %r25 atom.global.exch.b32 %r22,[atomic_lock],1;
> with no prior membar in GOMP_atomic_start.
I have:
...
@ %r25 atom.global.exch.b32 %r22,[atomic_lock],1;
@ %r25 membar.sys;
...
> Likewise with
> nvptx-none/lib/libgomp.a which has
> atom.global.exch.b32 %r22,[atomic_lock],1;
> I thought a barrier would show up there?
>
and:
...
atom.global.exch.b32 %r22,[atomic_lock],1;
membar.sys;
...
So both look as expect.
>> The atomic ops in nvptx.md have memmodel arguments, which are currently
>> ignored.
>> Handle these, fixing test-case fails
>> libgomp.c-c++-common/reduction-{5,6}.c
>> on volta.
>
> Is there a reason that PR target/96932 isn't listed in the
> ChangeLog?
Just that I'm going to mark it a duplicate when this is fixed.
> Or is it supposed that the barrier does not show up
> at GOMP_atomic_start (as it doesn't) and it should show up elsewhere
> and still help with those two testcases?
>
Nope, it should show up.
> Sorry for not having better news. (Unless I messed up and it is an
> issue on my side - but it doesn't look like.)
Well yes, it's possible that the patch somehow does not work, but then
you'll need to investigate why that is.
Thanks,
- Tom
