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

[Darius Rad <darius@bluespec.com>]

On Tue, Apr 16, 2024 at 09:04:24AM -0700, Palmer Dabbelt wrote:
> 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.
> 

At least build-many-glibcs, and more importantly the release notes,
indicate what is actually tested, which says something.

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

Sure, if we think that can be kept up to date.  I think I would rather take
an official position on what build-many-glibcs or the release testing means
for supported targets (if there isn't something glibc-wide already), then
we don't have another thing to maintain.

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