[Openmp-dev] Clang9 warning and compiler error with atomics

Thu Dec 5 17:37:22 PST 2019

My key point is: Is the mapping of the type in question"working" or not? If not, it should be an error, if it is working, no warning, only if we don't know, it should be a warning.

--
written from my phone

________________________________
From: Alexey Bataev <Alexey.Bataev at ibm.com>
Sent: Thursday, December 5, 2019 7:34:50 PM
To: Doerfert, Johannes <jdoerfert at anl.gov>
Cc: Jeffrey Kelling <j.kelling at hzdr.de>; Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com>; Sunita Chandrasekaran <schandra at udel.edu>; openmp-dev at lists.llvm.org <openmp-dev at lists.llvm.org>; Guido Juckeland <g.juckeland at hzdr.de>
Subject: RE: Clang9 warning and compiler error with atomics

1. The warning is emitted correctly, there is no bug. It just might be annoying but it warns correctly. I'll just put it under different warning group so it would be easier to disable it.
2. +1 here. It would be good if you could fix this bug. NVPTX backend doesn't support atomic loads for sure and some other instructions too.

Best regards,
Alexey Bataev

5 дек. 2019 г., в 20:05, Doerfert, Johannes <jdoerfert at anl.gov> написал(а):

My two cents,

1) while the standard might not guarantee proper mapping for non trivially copyable types, we should determine under which condition we can guarantee the expected behaviour and not issue a warning expect we have to. The warning should then inform the user why we couldn't and how it can be resolved.
Could anyone open a bug for this as well?

2) atomics should "work". I'll look into this with the caveat that the performance is hardware dependent. as Alexey mentioned, if the hardware doesn't provide direct support we'll need to emulate them which might be even more costly. Nevertheless, it should work and not error out.

Cheers,
  Johannes

--
written from my phone

________________________________
From: Alexey Bataev <Alexey.Bataev at ibm.com>
Sent: Thursday, December 5, 2019 5:30:23 PM
To: Jeffrey Kelling <j.kelling at hzdr.de>
Cc: Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com>; Sunita Chandrasekaran <schandra at udel.edu>; openmp-dev at lists.llvm.org <openmp-dev at lists.llvm.org>; Guido Juckeland <g.juckeland at hzdr.de>; Doerfert, Johannes <jdoerfert at anl.gov>
Subject: RE: Clang9 warning and compiler error with atomics

There is std::is_trivially_copyable trait, you can check if your types are actually trivially copyable.

std::is_trivially_copyable<type>::value is true if type is trivially copyable, false otherwise.

Here is the definition of trivially copyable types

https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable

Compiler relies on the standard here.

Best regards,
Alexey Bataev

5 дек. 2019 г., в 18:03, Jeffrey Kelling <j.kelling at hzdr.de> написал(а):

Hello Alexey.

The warning is definitely fired only for non-trivially copyable
types. But for each of them.
I am not completely sure what the definition of non-trivially copyable is, but
I would not expect the following:

* It is giving me warning for std::tuple:
warning: Non-trivial type 'std::__1::tuple<unsigned int *, unsigned int *,
unsigned int *, unsigned long>' is mapped, only trivial types are guaranteed
to be mapped correctly [-Wopenmp-target]

Tuple has a defaulted copy constructor according to the standard. However, the
example above does have pointers, so it may still warrant a warning, but it
would be nice if I could turn that one off separately.

* I also get a waring on another type:
warning: Non-trivial type 'const
alpaka::vec::Vec<std::__1::integral_constant<unsigned long, 1>, unsigned
long>' is mapped, only trivial types are guaranteed to be mapped correctly [-
Wopenmp-target]
This one also has default move and copy constructors. It only has one data
member:
TVal m_data[TDim::value == 0u ? 1u : TDim::value]; // TVal = unsigned long

While I do agree, that this type is anything bus trivial as a whole, it still
should not warrant this warning.

What I can do is to put this warning into a
different warning group, like -Wopenmp-mapping or something like this.
This would help a lot already, thanks.

Best Regards,

Jeffrey

Best regards,
Alexey Bataev

5 дек. 2019 г., в 16:49, Jeffrey Kelling <j.kelling at hzdr.de> написал(а):

Hello Alexey.

1. What is the preferrable way of fixing the problem with the warning? I
don't think we should throw it away because it may help developers to
identify possible prpblems with the offloading.

I agree, that the warning may be important, which is why it would be nice

it

it would not be spammed so much. I would suggest to not show the warning

if

the type is trivially copyable.

I some cases a warning might be useful if the type, even if trivially
copyable, has member of pointer of reference types. However, there should

be

separate flag to toggle this one (at least a no- flag), because I am
intentionally pushing pointer to device memory into the target region

this way

and thus the spam would continue. Maybe, if there is a reference member

the

warning would always make sense, because the reference can maybe only

refer to

something on the host.

2. It is known problem and
there is no quick way to fix it. Some of the atomic constructs are not
supported by the NVPTX backend. Possible solution is to use critical
sections or, maybe, intrinsics/builtins directly.

This is a good thing to note, thanks.

Best Regards,

Jeffrey Kelling

Best regards,
Alexey Bataev

5 дек. 2019 г., в 15:27, Narayanaswamy, Ravi
<ravi.narayanaswamy at intel.com> написал(а):

+Alexey

From: Sunita Chandrasekaran [mailto:schandra at udel.edu]
Sent: Wednesday, December 4, 2019 7:02 PM
To: openmp-dev at lists.llvm.org
Cc: Jeffrey Kelling <j.kelling at hzdr.de>; Guido Juckeland
<g.juckeland at hzdr.de>; Narayanaswamy, Ravi
<ravi.narayanaswamy at intel.com>; Doerfert, Johannes Rudolf
<jdoerfert at anl.gov> Subject: Clang9 warning and compiler error with
atomics

Hello Everyone

I guess I have not posted to this alias in the near past, but I

probably

*can* ! Guess we will find out :-)
(copying Ravi and Johannes just in case my mail doesn't get thru the
mailing list..please let me know)

Some of us are working on an application PIConGPU which is also one of

the

8 ORNL CAAR projects for Frontier system. There are 2 issues pointed

out

by the developer Jeffrey Kelling (copied here) while he is running

Alpaka

tests with LLVM.

1. Clang9 is spamming the a pointless warning:
warning: Non-trivial type 'const
alpaka::vec::Vec<std::__1::integral_constant<unsigned long, 1>,

unsigned

long>' is mapped, only trivial types are guara
nteed to be mapped correctly [-Wopenmp-target]

While we are aware that the warning will appear, we need to turn off
-werror because of this, may miss more important warnings due to the
spam. Jeff also does not want to turn of -Wopenmp-target, because these
should be the most interesting warnings. It would be nice, if this one
could be fixed.

2. Jeff also just encountered an internal compiler error with atomics

and

the NVPTX backend, and created a bug report:
https://bugs.llvm.org/show_bug.cgi?id=44219

Addressing these issues for CAAR is very time critical and that led me

to

send an email to this mailing list to get some quick advice/insights

into

both these issues.

Thank you very much for your time!!
Cheers
sunita

----------------------------------------
Sunita Chandrasekaran
Asst. Prof. Computer and Information Sciences
Affiliated, Center for Bioinformatics and Computational Biology
Affiliated, Data Science Institute
University of Delaware
430 Smith Hall, Newark, DE, USA
p: 302-831-2714 e: schandra at udel.edu
----------------------------------------
Adjunct Prof. Dept. of Computer Science
University of Houston, TX
----------------------------------------
CRPL
Research Group:
http://crpl.cis.udel.edu/
t: https://twitter.com/sunitachandra29
w: https://www.eecis.udel.edu/~schandra/

--
Dr. Jeffrey Kelling

Computational Science Group (FWCC)
Department of Information Services and Computing (FWC)
Building 613, Room 260
Phone: +49 - 351 - 260 3680

Helmholtz-Zentrum Dresden-Rossendorf e.V.
http://www.hzdr.de

Vorstand: Prof. Dr. Dr. h. c. Roland Sauerbrey
Vereinsregister: VR 1693 beim Amtsgericht Dresden
<smime.p7s>

--
Dr. Jeffrey Kelling

Computational Science Group (FWCC)
Department of Information Services and Computing (FWC)
Building 613, Room 260
Phone: +49 - 351 - 260 3680

Helmholtz-Zentrum Dresden-Rossendorf e.V.
http://www.hzdr.de

Vorstand: Prof. Dr. Dr. h. c. Roland Sauerbrey
Vereinsregister: VR 1693 beim Amtsgericht Dresden
<smime.p7s>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20191206/fffa6908/attachment-0001.html>