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
