This is an archive of the discontinued LLVM Phabricator instance.

[libomptarget][nfc] Move some source into common from nvptx
ClosedPublic

Authored by JonChesterfield on Nov 15 2019, 11:03 AM.

Details

Summary

[libomptarget][nfc] Move some source into common from nvptx

Moves some source that compiles cleanly under amdgcn into a common subdirectory
Includes some non-trivial files and some headers. Keeps the cuda file extension.

The build systems for different architectures seem unlikely to have much in
common. The idea is therefore to set include paths such that files under
common/src compile as if they were under arch/src as the mechanism for sharing.
In particular, files under common/src need to be able to include target_impl.h.

The corresponding -Icommon is left out in favour of explicit includes on the
basis that the it makes it clearer which files under common are used by a given
architecture.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptNov 15 2019, 11:03 AM

It breaks the build:

[547/1109] Building NVCC intermediate link file projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/omptarget-nvptx_intermediate_link.o 
FAILED: projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/omptarget-nvptx_intermediate_link.o
projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/src/./omptarget-nvptx_generated_data_sharing.cu.o:1:8: warning: null character(s) ignored [enabled by default]
ELF´)}xK#9_Z20isRuntimeI?dv
...
  • Remove whitespace change to data_sharing
JonChesterfield added a comment.EditedNov 15 2019, 11:41 AM

It breaks the build:

...omptarget-nvptx_generated_data_sharing.cu.o:1:8: warning: null character(s) ignored [enabled by default]
 ...

That's interesting. I see the same failure on one machine but not on a second so thought it was a quirk of the local setup. Please could you try the new revision? It leaves data_sharing.cu totally unchanged (the first revision ran that file through a remove-non-ascii perl fragment intended to patch up whatever character nvcc didn't like).

It breaks the build:

...omptarget-nvptx_generated_data_sharing.cu.o:1:8: warning: null character(s) ignored [enabled by default]
 ...

That's interesting. I see the same failure on one machine but not on a second so thought it was a quirk of the local setup. Please could you try the new revision? It leaves data_sharing.cu totally unchanged (the first revision ran that file through a remove-non-ascii perl fragment intended to patch up whatever character nvcc didn't like).

Nope, still the same. I think the reason is -x cu option in nvcc invocation command, obj file is treated as cuda source file with this option

JonChesterfield added a comment.EditedNov 15 2019, 12:57 PM

Nope, still the same. I think the reason is -x cu option in nvcc invocation command, obj file is treated as cuda source file with this option

Yep, good spot. -x cu is right for compiling the source but not for linking.

There's an alternative '-Xcompiler -x -Xcompiler cu', or '--compiler-options -x --compiler-options cu', but that also passes the arguments to gcc which errors with 'language not recognised'

Which I think means -x cu is not usable via cmake. How do you feel about shims like:

nvptx/loop.cu:
#include "common/src/loop.cpp"

Testing that approach now

  • Work around nvcc's limited support for overriding language

One request but I'm fine with the workaround (includes) if they solve the problem

openmp/libomptarget/deviceRTLs/common/debug.h
1

Please add the - C++ - annotation to header files

openmp/libomptarget/deviceRTLs/nvptx/cancel.cu
1 ↗(On Diff #229634)

This is not pretty but also not problematic. It's not like we have to maintain any more code, just a single file.

  • Add C++ annotation to leading comment in header files
JonChesterfield marked an inline comment as done.Nov 15 2019, 3:40 PM

Reinstating the unity.cu patch would equivalently work around the language override challenge. Happy to go that way instead if the single line task.cu et al are considered too ugly.

JonChesterfield added a comment.EditedNov 18 2019, 8:10 AM

Simplified initial suggestion by dropping the .cu => .cpp rename. If we agree on moving the source to a common location, I can follow up with some cmake that builds the corresponding files for amdgcn. Making the common code look less like cuda can happen later.

  • - drop the contentious file rename part
JonChesterfield edited the summary of this revision. (Show Details)Nov 18 2019, 8:35 AM

The patch does not break the build.

JonChesterfield added a comment.EditedNov 18 2019, 9:10 AM

The patch does not break the build.

Which patch do you refer to?

Neither the task.cu #include common/task.cpp nor moving task.cu without renaming break the build for me, but it's worth noting which configuration you've checked.

ABataev accepted this revision.Nov 18 2019, 9:13 AM

The patch does not break the build.

Which patch do you refer to?

Neither the task.cu #include common/task.cpp nor moving task.cu without renaming break the build for me, but it's worth noting which configuration you've checked.

I was just saying that the patch is good and it does not(!) break the build. SO, if everybody else is fine with it, you can land it.

This revision is now accepted and ready to land.Nov 18 2019, 9:13 AM

That's great, thanks. We will imminently have (a subset of) deviceRTL available for a second architecture. I'll look at the CMake next.

This revision was automatically updated to reflect the committed changes.