Re: [RFC] build-many-glibcs: Add a rv64gcbv-on-rv64gc/lp64d sub-variant

[Palmer Dabbelt <palmer@rivosinc.com>]

On Tue, 16 Apr 2024 07:55:38 PDT (-0700), Darius Rad wrote:
> On Mon, Apr 15, 2024 at 02:36:59PM -0700, Palmer Dabbelt wrote:
>> On Mon, 15 Apr 2024 13:24:14 PDT (-0700), Darius Rad wrote:
>> > Is this really lp64d?
>>
>> I guess that depend on what you mean by "ABI".  Passing `-march=rv64gv
>> -mabi=lp64d` will result in binaries that require the V extension to run,
>> but can be linked with any other binary that is compiled with `-mabi=lp64d`.
>> It's essentially the same as `-march=rv64g -mabi=lp64`, except for vector
>> instead of float.
>>
>
> Got it.  I thought that might be the case, but wasn't sure if the vector
> calling convention leaked in with the arch switch only (and not the abi).

The intent was to avoid that, but GCC-14 will be the first release with 
any meaningful vector codegen so I guess we'll find out if we have any 
bugs ;)

>> > What is the status of the vector ABI?
>>
>> We don't have a global vector ABI switch for GCC (ie, `-mabi=lp64dv`) and we
>> decided not to put on in for GCC-14.  We've essentially got all the
>> machinery there for it, as we've got the vector calling convention
>> attribute, but that came in pretty late and we decided it'd be better to
>> wait.
>>
>> I don't see any reason it'd miss GCC-15, but no promises as there's not even
>> a patch on the lists yet...
>>
>
> Understood.  Though when this hits, won't it be the most likely target for
> vector?  Meaning at that point, rv64gcbv/lp64d would be less useful or
> important.

I'm not really sure.  If I was building a system I'd want an 
lp64dv-flavored ABI, but if distros are already rv64gc/lp64d then 
rv64gcv/lp64d would provide a binary compatible upgrade path for them.  
Assuming we end up with some sort of glibc-hwcaps the rv64gcv/lp64d 
builds might be common.

It's kind of all just a guess until HW shows up, though...

>> > If we need to
>> > have (and test) more targets that are actually useful, so be it.  But we
>> > don't want to be stuck testing targets nobody uses or that provide no
>> > testing value, and removing them is usually harder than adding them.
>>
>> Ya, that's kind of my worry here.  We'd be going out on a limb here by
>> targeting something without hardware availability, we've already got some
>> baggage floating around from lightly-used targets and it'd be best to avoid
>> too much of that.
>>
>
> Maybe make an explicit note that if/when the vector ABI is in gcc, the
> target will be switched to that, rather than another target being added.
> Then there's some notice for people to not rely on rv64gcbv/lp64d, or at
> least put up support and/or evidence of a use case to retain the target.

Ya, I guess so far we've not really been explicit about what's supported 
in glibc and what's not -- there's some code in there to ban stuff like 
lv64f and some default ISAs in build-many-glibcs, but I don't know if 
any of that is really binding.

So maybe we should do a wiki entry with what configurations are actively 
tested and thus likely to work?

>> IMO it's really more of a question for users/distros -- and I'm definitely a
>> crazy person on that front, I run Gentoo ;)
>>