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

[Darius Rad <darius@bluespec.com>]

Is this really lp64d?  What is the status of the vector ABI?  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.


On Mon, Apr 15, 2024 at 12:24:15PM -0700, Palmer Dabbelt wrote:
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
> So this is very much an RFC.  I had written a commit message as
> 
>     This will hopefully be a widely used configuration in the future, but
>     it's not all that common right now.  That said, let's be proactive and
>     at start testing it.
> 
> but I even that's kind of a strong statement here so I'm just stashing
> it off to the side to be sure.
> 
> A few of us were talking about the GCC meeting last week, but I figured
> I'd send a glibc patch to at least start some discussion on the lists as
> something similar had come up in the TLSDESC thread and a while ago when
> we talked about glibc-hwcaps.
> 
> I'm not really sure what the right thing to do here is: we don't have
> broadly available hardware that supports these new extensions, but
> they're pretty much table stakes for hardware that's competitive with
> arm64/x86.  Without B and V we're going to end up piling up a ton of
> IFUNC-based routines to try and work around the base ISA, but those
> extensions are so fundamental to good codegen that it doesn't feel like
> we're going to get where we want with just IFUNCs.
> 
> Unfortunately I don't think we can drop support for the other base ISAs:
> the distros appear to be targeting rv64gc and that's the only common
> base for most hardware that's out there.  I guess we could drop support
> for the rv*ima-based base ISAs, but I'm not sure that buys us much:
> we've got a lot of embedded users so we won't be able to drop the GCC
> support for soft float, and dropping the glibc support puts us in a
> clunky spot for testing.
> 
> So we're probably stuck in a bit of a performance hole for a while.
> That said, we could at least put a stake in the ground and start testing
> some target with some newer extensions.  That way distros that want to
> try a larger base than rv64gc have something that's getting tested and
> is thus likely to work.  For GCC we ended up adding some test targets
> with pretty much all the non-embedded, but at least B and V seem like
> the bare minimum.
> 
> I'm not sure if all that is worth the extra build/test resource burden
> for everyone, though, particularly given the lack of hardware.
> ---
>  scripts/build-many-glibcs.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
> index ecc743e672..21da46dc4a 100755
> --- a/scripts/build-many-glibcs.py
> +++ b/scripts/build-many-glibcs.py
> @@ -411,7 +411,9 @@ class Context(object):
>                          os_name='linux-gnu',
>                          variant='rv64imafdc-lp64d',
>                          gcc_cfg=['--with-arch=rv64imafdc', '--with-abi=lp64d',
> -                                 '--disable-multilib'])
> +                                 '--disable-multilib']),
> +                        extra_glibcs=[{'variant': 'rv64gcbv-rv64gc-lp64d',
> +                                       'ccopts': '-march=rv64gcv_zba_zbb_zbs'}]
>          self.add_config(arch='s390x',
>                          os_name='linux-gnu',
>                          glibcs=[{},
> -- 
> 2