Re: [PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions

[Palmer Dabbelt <palmer@rivosinc.com>]

On Wed, 06 Sep 2023 13:43:08 PDT (-0700), fweimer@redhat.com wrote:
> * Palmer Dabbelt:
>
>> +        self.add_config(arch='riscv64',
>> +                        os_name='linux-gnu',
>> +                        variant='rv64imafdcb-lp64d',
>> +                        gcc_cfg=['--with-arch=rv64imafdc_zba_zbb_zbs', '--with-abi=lp64d',
>> +                                 '--disable-multilib'])
>
> I doubt we need a separate GCC configuration, you should be able to use
> the existing compiler for that and just change the glibc build flags.

Right now we're building a different GCC for each target, setting the 
default arch at GCC configure time.  I agree that's super inefficient, 
but it's what the other tagets do.  Sharing GCCs will also result in 
mixing up things like libgcc, which is kind of a double-edged sword.

I'm not sure what the right answer is here.  For the GCC CI we're 
trending towards a single target that contains most of the new 
extensions, maybe that's the right thing to do for glibc as well?  It's 
looking like there'll be a generation of hardware that has B but doesn't 
have V, though, which is sort of what this target is aimed at.

Also +Jeff, in case he has an opinion.

> I expect we need some sort of version check because these flags are
> rather recent, right?  To what extend do they actually impact code
> generation for glibc?

We've got two inline asm routines that use the B extensions (both Zbb):

sysdeps/riscv/string-fza.h:#if defined __riscv_zbb || defined __riscv_xtheadbb
sysdeps/riscv/string-fzi.h:#if defined __riscv_zbb || defined __riscv_xtheadbb

That's a pretty small diff, but it is code we're not testing -- not sure 
if that's worth a whole test config, though.

On the compiler side the B extensions have a pretty big impact on 
codegen: they add a bunch of common bit manipulation patterns (sign/zero 
extension, bit fields, C strings, etc).  None of that should change the 
ABI, so in theory we should be safe if the GCC test suite passes.  We do 
glibc builds as part of the GCC testing, but that usually targets 
released glibc versions so stuff might slip through.

So I guess again kind of a grey area.

>
> Thanks,
> Florian