On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreya...@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
