[REQUEST] Add support for the Intel DPC++ compiler

[jcranmer-intel]

The trunk version of the compiler is found at https://github.com/intel/llvm; released versions are available as part of the oneAPI toolkit downloads (which is already extracted for the newer icc/ifort versions).

This probably requires #2244 and a new SYCL language dropdown to make sense.

[zpyatt]

1st. Thanks or the awesome tool. 2nd I realize I'm asking someone else to do work for free so feel free to ignore me, but...

I'd be interested in this as well.

I'm curious how well OpenCL/SyCL for CPUs vectorizes/makes use of SIMD instructions.

Thanks

[rscohn2]

I would like to move this forward. I can do the changes, but need your advice on the best way to do it.

Being able to view generated device code would be useful using #2836. For now, I would be happy to get the compile/run working.

The compiler is already available on compiler explorer. It is icpx (C++ version of icx). The first issue is that compilation fails trying to find sycl-post-link: https://godbolt.org/z/chs5d4qd6

The compiler assumes that PATH includes /opt/compiler-explorer/intel-cpp-2022.0.1.71/compiler/latest/linux/bin so that it can find sycl-post-link. It is in the same directory as icpx. I have filed an issue asking that the compiler try to find sycl-post-link with a path relative to the compiler binary. If they are willing to make this change, then it would take several months before it would be available. Is there a way we can support it earlier? Setting PATH before launching a local instance works fine. I looked in c++.defaults.properties and I don't see anything that would set PATH. Any suggestions?

Assuming we get past that problem, the generated program will not run because it requires an rpath or LD_LIBRARY_PATH to point at /opt/compiler-explorer/intel-cpp-2022.0.1.71/compiler/latest/linux/lib. Setting LD_LIBRARY_PATH before launching a local compiler explorer instance does not work. Maybe it cleans the LD_LIBRARY_PATH before execution? What is the proper way to resolve this issue?

[partouf]

For the point about LD_LIBRARY_PATH, the recommended way is to use the compiler's ldPath property. An example can be found here

compiler-explorer/etc/config/c++.amazon.properties

Line 302 in 48eee26

compiler.clang1301.ldPath=${exePath}/../lib|${exePath}/../lib/x86_64-unknown-linux-gnu

For extending PATH, the only way is to override it in the compiler class, done like for example here

compiler-explorer/lib/compilers/pascal.js

Line 179 in 0bc22bb

execOptions.env.PATH = execOptions.env.PATH + ':' + this.nasmPath;

Currently icx/icpx doesn't use a custom compilerType, this will have to be added and used.

(The better way would of course be that icpx would actually know that it knows from which directory it's launched, because sycl-post-link is literally there next to icpx)

[rscohn2]

For the point about LD_LIBRARY_PATH, the recommended way is to use the compiler's ldPath property. An example can be found here

Thanks. Running is working now in my local instance where I set the PATH manually.

Currently icx/icpx doesn't use a custom compilerType, this will have to be added and used.
(The better way would of course be that icpx would actually know that it knows from which directory it's launched, because sycl-post-link is literally there next to icpx)

I will see what the developer says. I suppose I could change the installation procedure to create a shell script that wraps icpx in a shell script that sets the PATH.

icpx can also use OpenMP for GPU offload. It has the same issues: https://godbolt.org/z/bxWG4xboE

[rscohn2]

It looks like they have fixed the path issue and it is likely to be in the next release. When that comes out I will try to enable the device support from #2836. Since device support does not require compiling to a binary, it isn't dependent on fixing the the issues from #2246 (comment).

[partouf]

It's been a while, but I think this issue can be closed? Am I correct in that?

[rscohn2]

It's been a while, but I think this issue can be closed? Am I correct in that?

Yes. It is working well.