"gcn" vs. "amdgcn" etc. (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port)

[Thomas Schwinge]

Hi!

On 2019-12-03T13:13:33+0000, Andrew Stubbs <ams@codesourcery.com> wrote:
> On 02/12/2019 14:43, Thomas Schwinge wrote:
>> On 2019-11-12T13:29:13+0000, Andrew Stubbs <ams@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 658 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20191203/c64f785d/attachment.sig>