[llvm-dev] Clang option to provide list of target-subarchs.

[Rodgers, Gregory via llvm-dev]

Thank you for the feedback.

> How is this going to work with --target-subarchs?  Is there going to be a --no-target-subarchs flag to disable subarchs?  What will the semantics of this be, exactly?

The large number of subarchs expected makes an inclusive only flag desirable and an exclusive flag impractical.   Also, since subarchs will age more quickly than archs, who knows what old crufty subarchs you would get with an exclusion flag.   We expect that the runtime will match the most appropriate subarch. 
  
As is currently done with --cuda-gpu-arch, we expect that the triple for the arch will be implied from the context.   That is, if one specifies --target-subarchs="sm_50,gfx702", the software will generate the triples "nvptx64-nvidia-cuda" and "amdgcn--cuda" from the subarchs.    Collisions (different archs) for the same subarch are unlikely and indicate a poor choice of subarch names.   For example, AMD should never choose sm_ prefix for its subarchs.  

> ... than flags that deal in lists.  What are your thoughts about making it work that way instead?
The semantics of repeating a flag for each desired object verses a list does ease typing, which may not be justification enough.   But when they get lost and separated in long option lists, it could be frustrating.   Using a list, improves readability of scripts.  As we said, existing flags would still be supported.   

> what problem are we solving by putting "target" in the flag name?  We already have e.g. -march; it's not -mtarget-arch. "--offload-arch", maybe?

There are no problems solved with the word "target".  The genesis for me of this name is the association with OpenMP target pragmas used for offloading.    target is a noun and offload is a verb.  We desire a list of objects that end in s .    I am ok with archs instead of subarchs because it continues to imply some relationship with the arch field of the triple.  

I am ok with "--offload-archs"  .   If anyone has an issue with --offload-archs, please raise them here. 

Thank you 

Greg