Re: RISC-V: Support XTheadVector extensions

[Jeff Law <jeffreyalaw@gmail.com>]

On 11/28/23 12:45, Palmer Dabbelt wrote:

> 
> 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.
The way I think about the assembly bits is it allows us to share a good 
amount of code between the two implementations.  There's obviously going 
to be some differences that will require more extensive work and that's 
where I think most of our review effort ought to be.

> 
> 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.
The only P bits that made the gcc-14 deadline were those from Embecosm, 
so I'd tend to want to push all the other P stuff out to gcc-15.

> 
> So I think if the goal is to have a single vector target for RISC-V then 
> we've probably lost already.
That's probably not feasible.  But I think there's a good amount of 
sharable bits between the V1.0 and the thead-vector support.

> 
>> 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...]
It's aimed for evaluation/review given the submission occurred before 
the gcc-14 deadline.

jeff