[SYCL] Allow relaxed function pointer support in frontend

[Naghasan]

The patch enables the use of function pointer if the function has the indirectly callable attribute or is has a body. If the platform support function pointers, this allow extended support without requiring an interface to migrate / manage code available from the host.

The behaviour is control via an option on the -fsycl-allow-func-ptr flag.

This makes easier to support code ported over from cuda or using this mode #12757

[AlexeySachkov]

The patch enables the use of function pointer if the function has the indirectly callable attribute or is has a body. If the platform support function pointers, this allow extended support without requiring an interface to migrate / manage code available from the host.

How a user could understand if a platform supports function pointers? Is there an aspect they could check, or is there a documentation for that?

The behaviour is control via an option on the -fsycl-allow-func-ptr flag.
This makes easier to support code ported over from cuda or using this mode #12757

Does it imply that the suggested function pointers syntax is the final for SYCL? Because if not, I don't think that it is the best step in simplifying code porting because that code will have to be rewritten anyway. Note that we do not have a language extension specification which would document the attribute

[Naghasan]

Does it imply that the suggested function pointers syntax is the final for SYCL?

For the use case I'm doing this work for (CUTLASS), yes. When targeting nvidia, they want to keep the code as is. CUDA supports function pointers and so it is used. It is always used with defined function, hence the addition this relaxed mode: because the code will be in the TU, we don't need about a host API to make the code available (unlike VTable, but you know that better than me).

Though your comment made rethink that we shouldn't expose the flag as a driver one, will revert that part.

Note that we do not have a language extension specification which would document the attribute

Well aware of this, but that's intended to be used in pair with -fsycl-cuda-compat. So I'll document this as part of the compat mode once stable enough.

[Naghasan]

More comment on this PR ?

[Naghasan]

@AlexeySachkov more comments ?

[Naghasan]

@intel/llvm-gatekeepers this ready to be merged, failure are due to CI node having issues

[ldrumm]

I'd like to see a completed windows build before merging

[Naghasan]

D:\github\actions-runner_work\llvm\llvm\src\clang\include\clang/ASTMatchers/ASTMatchersInternal.h(1569): fatal error C1060: compiler is out of heap space

CI isn't working

[ldrumm]

I understand CI isn't working,

D:\github\actions-runner_work\llvm\llvm\src\clang\include\clang/ASTMatchers/ASTMatchersInternal.h(1569): fatal error C1060: compiler is out of heap space

CI isn't working

I can see that CI has failed for this run, but that doesn't mean your code isn't broken on Win32 with MSVC. I will merge if another windows runner can build this

[Naghasan]

well, still not better, ca1eafa was fine and clang won't build due to heap since this commit 5d20ee7

[Naghasan]

same issue with this PR #17552

[sarnex]

I gave more RAM to the Windows build VMs, so can you try again @Naghasan Thx

[Naghasan]

that will clash with #17559, so please hold the merge thanks