Can --offload-arch in fact be used for SPIR-V subarch specification?

[AGindinson]

After #4239 has switched CUDA/AMD architecture setting to the -Xsycl-target-backend --offload-arch mechanisms, there have been thoughts of specifying SPIR-V AOT architectures via the same mechanism instead of the llvm::Triple::SubArch once (corresponding FIXME: https://github.com/npmiller/llvm/blob/fad9c908e74af33d4b7eb0a898102c866ea0e48e/clang/lib/Driver/Driver.cpp#L4653-L4655).

There are 2 major concerns with such an approach:

1. How would the multi-arch compilation be managed? More specifically, what would become of the following command line: clang++ -fsycl -fsycl-targets=spir64_fpga,spir64_x86_64? The next iteration of such a multi-arch use-case would be the propagation of different BE compilation options to each of the AOT targets: clang++ -fsycl -fsycl-targets=spir64_fpga,spir64_x86_64 -Xsycl-target-backend=spir64_fpga "-cl-opt-disable" -Xsycl-target-backend=spir64_x86_64 "-cl-denorms-are-zero".
2. How would the backwards compatibility be retained, given that the subarch-based CLIs are used by the vast percentage of DPC++ users? A possible solution could be to retain the subarchs and insert deprecation warnings around these sites, but a) it would be difficult to estimate the migration period for users; b) would create large bulks of duplicate code at every site that distinguishes SYCL device toolchains by the SPIR-V architecture type.

While I personally view points 1-2 as sufficient to disregard the idea altogether, we could still use some unification for Intel GPU AOT compilations. More precisely, we can recommend to replace the following command line:

clang++ -fsycl -fsycl-targets=spir64_gen -Xsycl-target-backend "-device cfl"

with:

clang++ -fsycl -fsycl-targets=spir64_gen -Xsycl-target-backend "--offload-arch=cfl"

and create the -device argument value internally after parsing --offload-arch value at the same site as for CUDA and HIP. Granted, this wouldn't simplify the CLI for Gen AOT users, but would at least unify the interface for all supported GPU types.

I'd appreciate feedback regarding the 2 concerns and the alternative way for --offload-arch usage with SPIR-V subarchitectures. Inviting @npmiller @mdtoguchi @hchilama into the thread.

[npmiller]

@Naghasan do you have any input on this? @AidanBeltonS you might be interested in this discussion as well.