[PATCH] D60620: [HIP] Support target id by --offload-arch

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D60620#2064839 <https://reviews.llvm.org/D60620#2064839>, @yaxunl wrote:

> It means HIP will create two compilation passes: one for gfx908 and one for gfx908:xnack+:sramecc+.


OK, so empty feature list may also be valid.

> 
> 
>> One thing you'll need is a way to normalize the arch+features tuple so we can compare them.
> 
> We require features in target id follow a pre-defined order. This may not be alphabetical order since later on we may add more features.

Do you expect users to specify these IDs? How do you see it being used in practice? I think you do need to implement a user-friendly shortcut and expand it to the detailed offload-id internally. I'm fine with allowing explicit offload id as a hidden argument, but I don't think it's suitable for something that will be used by everyone who can't be expected to be aware of all the gory details of particular GPU features.

> 
> 
>> What I mean -- are users free to speficy any combination of {feature[+-]} and would it be expected for all/most of them to make sense to the user?
>> Or does it only make sense for a few specific arch:featureA+:featureB- combinations?
>> If we only have a limited set of valid combinations, it would make sense to give users easy-to-use names.
> 
> 
> 
>> I.e. if the only valid ids for gfx111 are gfx111:foo+:bar- and gfx111:buz+, we could call them gfx111a and gfx111b and expand it into the right set of features ourselves without relying on the users not to make a typo.
> 
> This was the scheme we used before but it did not work well.
> 
> For each GPU we have a predefined set of features. Currently some GPU's support xnack, some GPU's support sramecc, some GPU's support both. In the future we may introduce more features. If we let each GPU has its own encoding for features, it will be confusing since each letter will have different meanings depending on GPU. If we let all GPU share one encoding scheme, we are facing combination explosion. Most importantly, target ids are used by developers for whom the GPU+Features are meaningful terms to refer to a GPU configuration they want to compile for. For example, in daily life, we would say "we need to build for gfx908 with xnack on and sramecc off for this machine", then just use -offload-arch=gfx908:xnack+:sramecc- to compile. If we use an encoding for features, then developers have to look up the encoding scheme for xnack on and sramecc off, then use it in -offload-arch, which is inconvenient.

It sounds like we need both something easy to use for general users and full control for someone who needs it.
How about this -- keep `--gpu-arch=foo` as a user-friendly interface which only covers known released GPUs and allow using `--offload-id` as an alternative which allows precise control, if/when needed? `--gpu-arch=` will internally get treated as a predefined `--offload-id=...` for that GPU variant.


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

https://reviews.llvm.org/D60620