-
Notifications
You must be signed in to change notification settings - Fork 791
[SYCL] Remove math function decl in builtins.hpp #11014
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: jinge90 <[email protected]>
Signed-off-by: jinge90 <[email protected]>
Hi, @steffenlarsen |
Signed-off-by: jinge90 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with this if the frontend people are happy with the Sema solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why this is required? This seems strange to me. @AaronBallman @premanandrao can you take a look please?
Putting myself in reviewers just to get the notifications matching my outlook filters, please ignore it. |
With recent changes to SYCL builtin definitions, having conflicting math builtins in the global namespace may cause ambiguity errors for users with |
I'm working on a different approach to this - sycl...aelovikov-intel:llvm:no-complex-include. |
if (!Callee->getIdentifier()) | ||
return false; | ||
|
||
if (LibdeviceCmathSet.count(Callee->getName().str()) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing that confuses me is: aren't all these functions already builtins?
llvm/clang/lib/Sema/SemaSYCL.cpp
Line 4680 in 89e2280
if (!Callee->isDefined() && !Callee->getBuiltinID() && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the issue that the sycl versions of these functions don't get treated as builtins, so we need this new table to identify them?
Hi, all. |
Hi, @aelovikov-intel Thanks very much. Thanks very much. |
Can you elaborate on this please? What were the recent changes which introduced this ambiguity? By conflicting builtins, do you mean the ones in sycl/builtins.hpp and libm? Can you also answer @AaronBallman's question above? Why isn't the Does it make sense to avoid the SYCL_EXTERNAL error for all functions declared in system headers? |
Hi, @elizabethandrews and @AaronBallman |
This follows intel#11196 that did the same with <complex> before. We still want to support `std::` math functions in user code (as part of `sycl/doc/extensions/supported/C-CXX-StandardLibrary.rst`). Also, often times STL implements math functions support somewhat like this: ``` extern "C" { extern double cos (double __x) noexcept (true); } extern "C++" { namespace std __attribute__ ((__visibility__ ("default"))) { using ::cos; } } ``` As such, we still want to let the compiler know which symbols in the global namespace are known (e.g. `::cos`) and which aren't and need an error ( `SYCL kernel cannot call an undefined function without SYCL_EXTERNAL attribute`). One option to implement that is to recognize those functions as builtins in the front end (which intel#11014 tries to do). Another approach, taken in this PR, is to keep providing declaration in SYCL headers but only do so when customer included `<cmath>` explicitly (via `#include_next`, similarly to `<complex>` support added in intel#11196).
I read this as "there's no bug to be fixed" -- if the user passes |
This follows #11196 that did the same with <complex> before. We still want to support `std::` math functions in user code (as part of `sycl/doc/extensions/supported/C-CXX-StandardLibrary.rst`). Also, often times STL implements math functions support somewhat like this: ``` extern "C" { extern double cos (double __x) noexcept (true); } extern "C++" { namespace std __attribute__ ((__visibility__ ("default"))) { using ::cos; } } ``` As such, we still want to let the compiler know which symbols in the global namespace are known (e.g. `::cos`) and which aren't and need an error ( `SYCL kernel cannot call an undefined function without SYCL_EXTERNAL attribute`). One option to implement that is to recognize those functions as builtins in the front end (which #11014 tries to do). Another approach, taken in this PR, is to keep providing declaration in SYCL headers but only do so when customer included `<cmath>` explicitly (via `#include_next`, similarly to `<complex>` support added in #11196).
Hi, @AaronBallman |
I mean that if a user passes |
No description provided.