[PATCH] D98746: [clang][amdgpu] Use implicit code object default

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Great context, thanks guys. I had missed that part of the compiler.

We presently have a dependency edge from clang to the amdgcn target in llvm. The drawback I noticed here is it stops clang unconditionally building a runtime library for amdgcn. This patch, or a derivative of that, would hide that by making the dependency implicit. Unblocks openmp, which is important, but somewhat fragile.

Aside from that workaround, there are two subproblems here:

- Reporting deprecated argument and propagating the clang argument through to the backend, so that it doesn't have to be prefixed -mllvm by the user
- Clang emitting different IR based on different values for the code object format

The first part can be neatly solved as @yaxunl suggested above. Rewrite deprecated to new format, only pass either along if one was specified. That'll unblock openmp and break nothing. I'll put that change together.

The second is more troublesome. If clang emits different IR for different code object formats, then a device library built at clang build time (e.g. the openmp runtime) will need to be compiled N times for N different code object formats. Unfortunately, that library is already compiled M times for different architectures, so we're looking at N*M copies of roughly the same library, and logic in the clang driver to pick out the right one. Plus N extra paths to test/debug etc.

It would be preferable from an ease of use and distribution perspective if clang emits target id independent code and we specialise it later, either in the backend (at which point the backend really is the only thing that specifies a default), or as a library that is chosen by the driver during 'linking', like the device libs oclc_isa_version_906.bc pattern.

That is, we should make the target id implementation in clang more complicated by emitting some hook which is filled in later instead of hardcoding the code object version choice upfront, as that makes other stuff in the toolchain simpler. It would also turn the current work in progress from fragile into correct.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98746/new/

https://reviews.llvm.org/D98746