Hi Tom!

On 2022-05-13T16:20:14+0200, I wrote:
> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc <gcc@gcc.gnu.org> 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" <gcc-bugs@gcc.gnu.org> 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, <default> }.
>>>
>>> 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