[PATCH] D152882: [LinkerWrapper] Support device binaries in multiple link jobs

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D152882#4422797 <https://reviews.llvm.org/D152882#4422797>, @yaxunl wrote:

> In D152882#4422788 <https://reviews.llvm.org/D152882#4422788>, @jhuber6 wrote:
>
>> In D152882#4421138 <https://reviews.llvm.org/D152882#4421138>, @yaxunl wrote:
>>
>>> However, bitcode of  target ID gfx90a:xnack+ is allowed to link in bitcode of target ID gfx90a as long as they are from different containers. So there are two rules about target ID: 1. compatibility rules for objects/bitcode in the same container 2. compatibility rules for linking bitcode of different target ID's.
>>>
>>> we need tests for both rules.
>>
>> So I'm wondering why I'm allowed to do `--offload-arch=gfx90a,gfx90a:xnack+`. Shouldn't that be caught by `getConflictTargetIDCombination`? That seems like the proper place to diagnose this.
>
> clang --offload-arch=gfx90a,gfx90a:xnack+ -c a.hip
> clang: error: invalid offload arch combinations: 'gfx90a' and 'gfx90a:xnack+' (for a specific processor, a feature should either exist in all offload archs, or not exist in any offload archs)
>
> At least it is caught for HIP. OpenMP may not check that.



  if (Kind != Action::OFK_HIP)
    return std::nullopt;

Yes, this would be the culprit. Guessing we shouldn't do that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152882