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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
