intel
Add a way to see all possible values for `-fsycl-targets` flag
Is your feature request related to a problem? Please describe
This is split from #1191 where folks were confused about which targets are supported by our SYCL implementation and which spelling should be used for them, i.e. what are the possible values for -fsycl-target compiler flag?
Describe the solution you would like
There is no proposal for this yet and the solution/interface should be developed as part of this issue. Original issue mentioned -fsycl-targets=list as an example of how it could be used. Displaying the full list under --help is also an option
Describe alternatives you have considered
No response
Additional context
No response
Hey, just wondering: Would this list all possible -fsycl-targets? or just the ones supported by the build of the compiler? (For example, if we build the compiler without cuda support it wouldn't list the nvptx64-nvidia-cuda target)
For example, if we build the compiler without cuda support it wouldn't list the nvptx64-nvidia-cuda target
From a user's perspective, this would be bad. It would be best if only those targets supported by the compiler (or its plugins 😬) will be listed
Hey, just wondering: Would this list all possible
-fsycl-targets? or just the ones supported by the build of the compiler? (For example, if we build the compiler without cuda support it wouldn't list the nvptx64-nvidia-cuda target)
Theoretically, yes. Our build scripts have a knowledge about which targets/backends are being built. I'm not entirely sure if those have a direct mapping to SYCL targets, but that is definitely something that we can propagate ourselves through our own CMake options from our configure.py script if that would be needed.
For example, if we build the compiler without cuda support it wouldn't list the nvptx64-nvidia-cuda target
From a user's perspective, this would be bad. It would be best if only those targets supported by the compiler (or its plugins 😬) will be listed
Plugins are dynamically loaded and compiler can't know which plugins will be available on a system that is going to execute an application. There maybe zero plugins available during build and that's fine. Therefore, I don't think that we will be able to be precise (or even reasonable) with our assumptions about available plugins at compile-time.
Sorry, my quote was wrong. What would be bad is:
Would this list all possible @-fsycl-targets@?
Plugins are dynamically loaded and compiler can't know which plugins will be available on a system that is going to execute an application.
I see. Makes sense.