Hi! On 2019-12-03T13:13:33+0000, Andrew Stubbs <a...@codesourcery.com> wrote: > On 02/12/2019 14:43, Thomas Schwinge wrote: >> On 2019-11-12T13:29:13+0000, Andrew Stubbs <a...@codesourcery.com> wrote: >>> --- a/include/gomp-constants.h >>> +++ b/include/gomp-constants.h >>> @@ -174,6 +174,7 @@ enum gomp_map_kind >>> #define GOMP_DEVICE_NVIDIA_PTX 5 >>> #define GOMP_DEVICE_INTEL_MIC 6 >>> #define GOMP_DEVICE_HSA 7 >>> +#define GOMP_DEVICE_GCN 8 >> >> Unless we are to expect non-AMD GCN implementations (hardware), I'd favor >> if all these "GCN" things were called "AMD GCN", like done for "Nvidia >> PTX", or "Intel MIC", or why shouldn't we? > > Why do we do that for libgomp
I don't remember how that happened. Now, I guess I understand 'GOMP_DEVICE_NVIDIA_PTX' to mean: loading/executing PTX code by means of its "native" Nvidia mechanism (CUDA Driver library). There could then also be a 'GOMP_DEVICE_NOUVEAU_PTX' (or 'GOMP_DEVICE_MESA_PTX'?), for example. > but not for GCC in general? I mean, it's > not "Intel i386" or "Renesas SuperH" (or should that be "Hitachi"?). The > only GCC port that has the company name is the "nv" in "nvptx" (ignoring > those where the company and architecture are the same). > > We use "amdgcn" for the target triplet, but it's just "gcn" almost > everywhere else, You also used "amdgcn" in the tag in the email subject. ;-P > including the config directories. Yeah, I guess that's what I find confusing here, that for most of all GCC back ends (not all, however...) there seems to be consistency between the "CPU" part of the target triplet and the corresponding GCC back end name/directory: $ cd gcc/config/ && for f in *; do test -d "$f"/ && echo "$f $( ../../config.sub "$f" )"; done aarch64 aarch64-unknown-none alpha alpha-unknown-none arc arc-unknown-none arm arm-unknown-none avr avr-unknown-none bfin bfin-unknown-none bpf bpf-unknown-none c6x tic6x-unknown-coff cr16 cr16-unknown-elf cris cris-axis-none csky csky-unknown-none epiphany epiphany-unknown-none fr30 fr30-unknown-none frv frv-unknown-none ft32 ft32-unknown-none Invalid configuration `gcn': machine `gcn-unknown' not recognized gcn h8300 h8300-unknown-none i386 i386-pc-none ia64 ia64-unknown-none iq2000 iq2000-unknown-none lm32 lm32-unknown-none m32c m32c-unknown-none m32r m32r-unknown-none m68k m68k-unknown-none mcore mcore-unknown-none microblaze microblaze-xilinx-none mips mips-unknown-elf mmix mmix-knuth-mmixware mn10300 mn10300-unknown-none moxie moxie-unknown-none msp430 msp430-unknown-none nds32 nds32-unknown-none nios2 nios2-unknown-none nvptx nvptx-unknown-none or1k or1k-unknown-none Invalid configuration `pa': machine `pa-unknown' not recognized pa pdp11 pdp11-dec-none pru pru-unknown-elf riscv riscv-unknown-none rl78 rl78-unknown-none rs6000 rs6000-ibm-aix rx rx-unknown-none s390 s390-ibm-aix sh sh-unknown-none sparc sparc-sun-sunos4.1.1 Invalid configuration `stormy16': machine `stormy16-unknown' not recognized stormy16 tilegx tilegx-unknown-linux-gnu tilepro tilepro-unknown-linux-gnu v850 v850-unknown-none vax vax-dec-ultrix4.2 visium visium-unknown-none vms vax-dec-vms xtensa xtensa-unknown-none We probably can't/shouldn't change 'amdgcn' in the target triplet now, but as far as I'm concerned, it's not too late to change 'gcc/config/gcn' etc., but I guess that won't happen: too much effort. (And then, I don't feel too stronly about it, but wanted to make my point anyway.) And, I acknowledge that by some of the logic I presented above, indeed 'nvptx' should've been called 'ptx' to denote purely the PTX ISA, outside of its Nvidia implementation. Naming is hard. ;-) Grüße Thomas
signature.asc
Description: PGP signature