Hi Tom! Ping. Grüße Thomas On 2022-07-20T14:46:03+0200, I wrote: > 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