https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I'll also cite my response in https://mailman.openmp.org/mailman/private/omp-lang/2020/016879.html "The rationale for not using sm_XX for arch is that at least users of compilers that target more than one CPU or GPU architecture should be able to distinguish not just between different architectures of one kind of CPU (or GPU etc.), but also in between them, furthermore e.g. for ISA there could be overlaps in the names, not all instruction set architecture extensions have unique names, so if e.g. (made up) both picochip and mmix call some of their instruction set architecture extensions v1.0, v1.1 and v1.2, the user is able to distinguish, by writing device={arch(picochip),isa(v1.1)} or device={arch(mmix),isa(v1.1)} Both arch and isa are fuzzy terms, isa even stands for instruction set ARCHITECTURE. The only hint the specification gives is that the scoring order is kind, arch, isa and so IMNSHO we should treat kind (is this cpu, gpu or fpga (or host/nohost)) as the hierarchically highest category, then the division into major cpu (or gpu or fpga) architectures and as the third level the even smaller details. If one uses just sm_XX for arch and cc_XX for isa, there is no way to say that you actually have in mind the nvidia GPGPUs, as opposed to some other GPGPU that happens to call some instruction set or part of it sm_XX. So, I'd prefer if the arch names were something clearly unique, that there is no other cpu/gpu/fpga with such a name or that it is obvious what kind of arch it is for most users. People working with nvidia GPGPUs will know what sm_XX means, but people that only do CPU programming on say mainframe will know the different isas of their architecture but not have an idea what sm_XX could mean. So nvptx looks like a better name to me, that includes the nvidia part as well as the ptx that is significant, because nvidia could in 10-20 years use completely incompatible architecture, or the gpus from 10-20 years ago weren't compatible either. The border line is names in common use that both uniquely identify the cpu/gpu/fpga major architecture/ABI, but also the architecture level. E.g. power8 includes in the name both the major architecture (power) and the ISA level. Though, it doesn't include other important part of the ABI, namely is this 32-bit or 64-bit, little-endian or big-endian and is it (when on Linux) ELFv1 or ELFv2. So, perhaps power8 is not the best arch (and what would be isa in that case anyway), and we want powerpc to stand for any powerpc-ish, powerpc32 for 32-bit big-endian, powerpc64 for 64-bit big-endian and powerpc64le for 64-bit little-endian as arch and then use power5/power6/power7/power8/power9 etc. as isa. Though, maybe instead powerpc should stand for 32-bit powerpc and powerpc32 shouldn't exist, perhaps more people will understand it that way. Another example is s390 (System-Z), some of the ISA levels at least include the z, but it isn't sufficiently unique IMHO, so z900 or z196 aren't the best arch candidates, but e.g. arch13 is even worse, that is always wrong for arch, because you can have arch13 on many CPUs. So, I think s390 (for 31-bit) and s390x for (64-bit), unsure if something for both, are better arch names, and keep z900, z196, zEC12, z15 etc. as isa names. The context selectors can contain vendor too, but that is in implementation and at least to me is about the software stack (i.e. software vendor which can but doesn't have to be the corresponding hw vendor), rather than vendor of some hw (and what exactly, many devices contain parts from many different vendors). We don't right now have anything to identify the operating system (Linux, Windows, MacOS, FreeBSD, AIX, VMS, ...), if we want that, I think that would go into implementation."
