One interesting thing about the EDG front end is that it can emulate all the others (and in various versions of the others) and what they support, and the errors they might detect.
It isn't perfect, but it is awfully good.
Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.
This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.
The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.
No, we only parse the language, do full semantic analysis, and optionally lower the representation to something that roughly matches C-language semantics. (That lowering can do some minimal inlining if needed, but that's a historical thing.)
We have two "back ends": c_gen_be.c generates C code from the lower IL ("intermediate language"; EDG's term for the AST) and cp_gen_be.c generates C++ code from the unlowered IL.
Several of our customers instrument the AST to add security-probing and/or other dynamic-analysis features.
NVCC uses it to separate out "device" constructs.
Yes. And this is why the nvcc preprocessor is so effective at working with the various host compilers. It emulates properties of the host compiler so that the device code and host agree on things.
But i could not find Thibaut Lutz's presentation slides linked to in the above discussion. Any idea where i can find it?
I presume the control flow in the above presentation is the same as found in "The CUDA Compilation Trajectory" chapter in the NVCC documentation (cudafe++ is EDG) - <a href="https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#the-cuda-compilation-trajectory" rel="nofollow">https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index...
compiler-guy · · focus · HN ↗
It isn't perfect, but it is awfully good.
Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.
This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.
The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.
feelamee · · focus · HN ↗
daveedvdv · · focus · HN ↗
We have two "back ends": c_gen_be.c generates C code from the lower IL ("intermediate language"; EDG's term for the AST) and cp_gen_be.c generates C++ code from the unlowered IL.
rramadass · · focus · HN ↗
daveedvdv · · focus · HN ↗
saagarjha · · focus · HN ↗
compiler-guy · · focus · HN ↗
You can see some discussion here:
<a href="https://forums.developer.nvidia.com/t/nvcc-preprocessing/64939/7" rel="nofollow">https://forums.developer.nvidia.com/t/nvcc-preprocessing/649...
rramadass · · focus · HN ↗
But i could not find Thibaut Lutz's presentation slides linked to in the above discussion. Any idea where i can find it?
I presume the control flow in the above presentation is the same as found in "The CUDA Compilation Trajectory" chapter in the NVCC documentation (cudafe++ is EDG) - <a href="https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#the-cuda-compilation-trajectory" rel="nofollow">https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index...