Re: RISC-V: Support XTheadVector extensions

[Palmer Dabbelt <palmer@dabbelt.com>]

On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreyalaw@gmail.com wrote:
>
>
> On 11/17/23 16:16, 钟居哲 wrote:
>>  >> I assume this hunk is meant for riscv_output_operand in riscv.cc.  We
>>>>may also need to add '^' to the punct_valid_p hook.  But yes, this is
>>>>the preferred way to go when all we need to do is prefix the instruction
>>>>with "th.".
>>
>> No. I don't think we need to add '^' . I don't want theadvector to touch
>> any codes
>> of vector.md.
>> Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain.
>> People like me don't want to touch any thing related to Thead.
>> But anyway, I will take care of that in GCC-15.
> I suspect it's going to be even worse if you we have multiple patterns
> with the same underlying RTL, but just different output strings.
>
> The standard way to handle that has been with an output modifier and/or
> ASSEMBLER_DIALECT.  If you look at the PA port for example, the
> assembler syntax changed dramatically between the PA1.0/PA1.1 era and
> the PA2.0 era.  But we support both variants trivially without
> duplicating all the patterns.

IMO we're just stuck between a rock and a hard place here.  
Specifically, this isn't just an assembly syntax change but also comes 
with a bunch of behaviorial changes to the instructions in question -- 
I'm specifically thinking of things like the register packing, which 
IIRC changed a ton between 0.7 and 0.8 (and then again more for 1.0).  
That's the kind of stuff that tends to have non-local implications on 
the port, and thus can trip people up.

So if we model this as just assembly syntax then we risk people tripping 
over the differences, but if we try to model it as a whole different 
extension then we have more code to manage.  I'd start with the assembly 
syntax approach, as it should be the option with less code which is 
always nice.  If that turns out to be a problem then we can always just 
duplicate the patterns, but it's way harder to merge them back together 
if we start out with things duplicated.

During the patchwork call we also ended up talking about the P extension 
(and the likely vendor flavors).  Nothing's appeared for there yet, but 
the theory is that the RZ/Five (Renesas' line of RISC-V chips that came 
out earlier this year) has some P-related extension.  There's also some 
SIMD in CORE-V, as well as a bunch of low-hanging fruit missing from V 
that we'll probably see more vendor extensions for.

So I think if the goal is to have a single vector target for RISC-V then 
we've probably lost already.

> But we've got time to sort this out.  I don't think the code in question
> was targeted towards gcc-14.

[In case anyone else is watching: see the forked thread, it might be 
amied for 14 now...]

>
>
> jeff