Hi Tom! Ping. Grüße Thomas On 2022-07-13T10:42:44+0200, I wrote: > Hi Tom! > > Ping. > > > Grüße > Thomas > > > On 2022-07-05T16:59:23+0200, I wrote: >> Hi Tom! >> >> Ping. >> >> >> Grüße >> Thomas >> >> >> On 2022-06-15T23:18:10+0200, I wrote: >>> Hi Tom! >>> >>> On 2022-05-13T16:20:14+0200, I wrote: >>>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote: >>>>> On 2/4/22 08:21, Thomas Schwinge wrote: >>>>>> On 2022-02-03T13:35:55+0000, "vries at gcc dot gnu.org via Gcc-bugs" wrote: >>>>>>> I've tested this using (recommended) driver 470.94 on boards: >>>> >>>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { GOMP_NVPTX_JIT=-O0, }. >>>>>> >>>>>> Do you use separate (nvptx-none offload target only?) builds for >>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the >>>>>> multilib configuration? >>>>> >>>>> Neither, I'm using --target_board=unix/foffload= for that. >>>> >>>> ACK, I see. So these flags then only affect GCC/nvptx code generation >>>> for the actual user code (here: GCC libgomp test cases), but for the >>>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp -- >>>> the latter especially relevant for OpenMP), it uses PTX code from one of >>>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'. >>>> >>>> Meaning, one can't just use such a flag for "completely building code" >>>> for a specific configuration. Random example, >>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target >>>> libraries aren't being built for '-march=sm_75' multilib, >>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib, >>>> which isn't '-march=sm_75'. >>>> >>>> >>>>> ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS' >>>>>> etc., I suppose?) Should we add a few representative configurations to >>>>>> be built by default? And/or, should we have a way to 'configure' per >>>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a >>>>>> few other targets?)? (I see there's also a new >>>>>> '--with-multilib-generator=[...]', haven't looked in detail.) No matter >>>>>> which way: again, combinatorial explosion is a problem, of course... >>>>> >>>>> As far as I know, the gcc build doesn't finish when switching default to >>>>> higher than sm_35, so there's little point to go to a multilib setup at >>>>> this point. But once we fix that, we could reconsider, otherwise, >>>>> things are likely to regress again. >>>> >>>> As far as I remember, several issues have been fixed. Still waiting for >>>> Roger's "middle-end: Support ABIs that pass FP values as wider integers" >>>> or something similar, but that PR104489 issue is being worked around by >>>> "Limit HFmode support to mexperimental", if I got that right. >>>> >>>> Now I'm not suggesting we should now enable all or any random GCC/nvptx >>>> multilibs, to get all these variants of GCC/nvptx target libraries built; >>>> especially also given that GCC/nvptx code generation currently doesn't >>>> make too much use of the new capabilities. >>>> >>>> However, we do have a specific request that a customer would like to be >>>> able to change at GCC 'configure' time the GCC/nvptx default multilib >>>> (including that being used for building corresponding GCC/nvptx target >>>> libraries). >>>> >>>> Per 'gcc/doc/install.texi', I do see that some GCC targets allow for >>>> GCC 'configure'-time '--with-multilib-list=[...]', or >>>> '--with-multilib-generator=[...]', and I suppose we could be doing >>>> something similar? But before starting implementing, I'd like your >>>> input, as you'll be the one to approve in the end. And/or, maybe you've >>>> already made up your own ideas about that? >>> >>> So, instead of "random GCC/nvptx multilib configuration" (last >>> paragraph), I've come up with a way to implement our customer's request >>> (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'. >>> >>> I think I've implemented this in a way so that "random GCC/nvptx multilib >>> configuration" may eventually be implemented on top of that. For easy >>> review/testing I've split my changes into three commits, see attached >>> "nvptx: Make default '-misa=sm_30' explicit", >>> "nvptx: Introduce dummy multilib option for default '-misa=sm_30'", >>> "nvptx: Allow '--with-arch' to override the default '-misa'". >>> >>> To the best of my knowledge, the first two patches do not change any >>> user-visible behavior (I generally 'diff'ed target libraries, and >>> compared a good number of 'gcc -print-multi-directory [flags]'), and >>> likewise with the third patch, given implicit (default) or explicit >>> '--with-arch=sm_30', and that with '--with-arch=sm_70', for example, the >>> '-misa=sm_70' multilib variants are used for implicit (default) or >>> explicit '-misa=sm_70' or higher, and the '-misa=sm_30' multilib variants >>> are used for explicit lower '-misa'. >>> >>> What do you think, OK to push to master branch? >>> >>> >>> Grüße >>> Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955