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