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