With nvcc, it’s possible to provide a host compiler via the --ccbin argument. I don’t see any reference to this in the nvc++ documentation and wanted to confirm – is this possible with nvc++?
Thanks,
Matt
I’m not clear if you’re asking if nvc++ can be used as the host compiler for nvcc (yes it can) or if nvc++ has a similar “–ccbin” flag (no, it’s not needed)?
nvcc uses a split compilation model where it will split code into device and host versions compiling each separately using a supplied host compiler for the host version.
nvc++ does both in single compilation pass.
Bryce gives a good explanation in his GTC talk from a few years ago starting around the 16:15 minute mark: Inside NVC++ and NVFORTRAN - Bryce Adelstein Lelbach - GTC 2021 - YouTube
I’m not clear if you’re asking if nvc++ can be used as the host compiler for nvcc (yes it can) or if nvc++ has a similar “–ccbin” flag (no, it’s not needed)?
Sorry for the confusion, my question was the latter. We’re using nvc++ for device offloading via OpenMP directives, but we have some CPU-based code that we’d like to use an Intel compiler for. In my mind, this situation isn’t too dissimilar from situations where you use nvcc, in this case we’re just achieving the kernel part with device offloading instead of writing them by hand. Out of curiosity, why would you say that’s not needed? I can see the difference between the single and two-pass being a more technical reason as to why, but wanted to make sure I wasn’t missing your point.
Because nvc++ is already both the host and device compiler. No separate host compiler is needed.
We’re using nvc++ for device offloading via OpenMP directives, but we have some CPU-based code that we’d like to use an Intel compiler for. In my mind, this situation isn’t too dissimilar from situations where you use nvcc,
It’s very different. With OpenMP target offload, the compiler not only needs to generate the device code, but also the host fallback code and all the set-up code needed for the kernel launches. There also all the memory management. You can’t just extract the device code and have it called elsewhere.
Now nvc++ is object compatible with ipcx, so you can mix objects compiled by different compilers within the same binary. Linking is a bit of pain since you then need to explicitly include the runtime libraries from the compiler that you’re not using to link, but once you get the recipe, it’s usually not too bad.
It’s best to use nvc++ to link since we do a device link step that others don’t. If you do link with a different compiler, then you need add “-gpu=nordc” to the nvc++ compilation. “RDC” is relocatable device code which enables features such as accessing global device variables or calling cross file device routines, which require the device linking. If you don’t need these features, then using nordc is fine.