This is an archive of the discontinued LLVM Phabricator instance.

[libomptarget] Replace INLINE with DEVICE to work around nvcc deleting forceinline symbols
AbandonedPublic

Authored by JonChesterfield on Nov 5 2019, 10:11 AM.

Details

Summary

[libomptarget] Replace INLINE with DEVICE to work around nvcc deleting forceinline symbols

There is a problem with some installs of nvcc deleting the forceinline symbols
from support.cu. Adding the people who reported this as reviewers. This patch is
an educated guess at a fix, posting it without a local repro for the failure. See D69859 for an alternative.

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptNov 5 2019, 10:11 AM

What about the inlining, will it affect it?

JonChesterfield added a comment.EditedNov 5 2019, 10:13 AM

What about the inlining, will it affect it?

I've given up on guessing what nvcc will do. Changing the INLINE macro to __inline__ (and away from the possibly buggy __always_inline__) is a nicer fix if it works.

Working theories:

  • nvcc requires declaration and definition to have identical attributes
  • nvcc __always_inline__ is broken
  • nvcc changes the semantics of code based on #include hierarchy

I'm still trying to reproduce the missing symbols locally so don't have much scope for experimentation.

^ for always_inline, please read forceinline...

What about the inlining, will it affect it?

I've given up on guessing what nvcc will do. Changing the INLINE macro to __inline__ (and away from the possibly buggy __always_inline__) is a nicer fix if it works.

Working theories:

  • nvcc requires declaration and definition to have identical attributes
  • nvcc __always_inline__ is broken
  • nvcc changes the semantics of code based on #include hierarchy

I'm still trying to reproduce the missing symbols locally so don't have much scope for experimentation.

Try to replace with __inline__, I will try this patch locally with my version of Cuda. Also, I don't think it is nvcc, I think we get something bad with clang/LLVM inlining, when we try to link against .bc library.

JonChesterfield retitled this revision from [libomptarget] Replace INLINE with DEVICE to work around nvcc deleting always_inline symbols to [libomptarget] Replace INLINE with DEVICE to work around nvcc deleting forceinline symbols.Nov 5 2019, 10:40 AM
JonChesterfield edited the summary of this revision. (Show Details)
JonChesterfield edited the summary of this revision. (Show Details)Nov 5 2019, 10:42 AM

Try to replace with __inline__, I will try this patch locally with my version of Cuda. Also, I don't think it is nvcc, I think we get something bad with clang/LLVM inlining, when we try to link against .bc library.

Thanks. D69859 for the forceinline to inline change. That's appealing in that we used to use inline.

This one ends up with the multiply defined symbols instead :)

This one ends up with the multiply defined symbols instead :)

How? The functions are only defined in support.cu and it's only compiled once. Where are the duplicates from?

This one ends up with the multiply defined symbols instead :)

How? The functions are only defined in support.cu and it's only compiled once. Where are the duplicates from?

No idea, llvm-link reports multiply defined functions.

JonChesterfield added a comment.EditedNov 5 2019, 12:20 PM

This one ends up with the multiply defined symbols instead :)

How? The functions are only defined in support.cu and it's only compiled once. Where are the duplicates from?

No idea, llvm-link reports multiply defined functions.

Why is llvm-link involved? I thought nvcc generated object files (ptxas, possibly sass).

I believe there are two compilation paths in the nvptx cmake. One includes everything into unity.cu and passes that to nvcc, which builds a single object file. The other builds each file individually with clang and passes the result to llvm-link. The most likely explanation at this point is that I've totally misunderstood what the cmake file is supposed to be doing, and thus failed to modify it appropriately.

This one ends up with the multiply defined symbols instead :)

How? The functions are only defined in support.cu and it's only compiled once. Where are the duplicates from?

No idea, llvm-link reports multiply defined functions.

Why is llvm-link involved? I thought nvcc generated object files (ptxas, possibly sass).

I believe there are two compilation paths in the nvptx cmake. One includes everything into unity.cu and passes that to nvcc, which builds a single object file. The other builds each file individually with clang and passes the result to llvm-link. The most likely explanation at this point is that I've totally misunderstood what the cmake files is supposed to be doing, and thus failed to modify it appropriately.

.bc files are linked with llvm-link. the library is compiled by both, nvcc (to generate .a library) and clang + llvm tools (to generate .bc library). .bc is used for generating of the most optimal code with inlined runtime library.

I think we should apply this patch anyway. It fixes the nvcc build which we have multiple reports of breakage from.

I can't see a reason why clang would conjure duplicate symbols, and have failed to reproduce anything like that, so am hopeful that it's a quirk of your current build setup.

Fundamentally I believe that nvcc would fail to handle inline functions correctly, as it fails to do a bunch of things correctly, and I believe that clang will build this correctly from a clean directory.

Otherwise, please provide enough details of your build setup that I can reproduce the failure.

I think we should apply this patch anyway. It fixes the nvcc build which we have multiple reports of breakage from.

I can't see a reason why clang would conjure duplicate symbols, and have failed to reproduce anything like that, so am hopeful that it's a quirk of your current build setup.

Fundamentally I believe that nvcc would fail to handle inline functions correctly, as it fails to do a bunch of things correctly, and I believe that clang will build this correctly from a clean directory.

Otherwise, please provide enough details of your build setup that I can reproduce the failure.

Bad decision. I would suggest to revert your pr3vious patches and restore intial code layout and then try step by step fixing it.

Bad decision. I would suggest to revert your pr3vious patches and restore intial code layout and then try step by step fixing it.

Well, we can't leave trunk broken. So sure, feel free to revert them.

However I cannot debug errors which only occur on other developers machines when using closed source compilers. So I can't fix it later either.

Bad decision. I would suggest to revert your pr3vious patches and restore intial code layout and then try step by step fixing it.

Well, we can't leave trunk broken. So sure, feel free to revert them.

It takes too much time, better you to revert them as yoh're much more familiar with the changes you landed.

However I cannot debug errors which only occur on other developers machines when using closed source compilers. So I can't fix it later either.

I can try them locally and can say if they break something or not before yoj will try to commit them.

It takes too much time, better you to revert them as yoh're much more familiar with the changes you landed.

I can try them locally and can say if they break something or not before yoj will try to commit them.

Patch at D69885.

JonChesterfield abandoned this revision.Nov 12 2019, 8:37 AM