I prefer ASM_OUTPUT_OPCODE or assembler dialect to %^ and I don't want to see
any change of vector.md.
%^ will cause high burden for future maintainment.
Besides, ASM_OUTPUT_OPCODE can the whole string. My patch is just a draft.
We can exlude for example, in zvbb, we can exclude appending "th."
On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 wrote:
>
> I am totally ok to approve theadvector on GCC-14 before stage 3 close
> as long as it doesn't touch the current RVV codes too much and binutils
> supports theadvector.
>
> I have provided the draft approach:
> https://gcc.gnu.org/pipermail/gcc-patche
I am totally ok to approve theadvector on GCC-14 before stage 3 close
as long as it doesn't touch the current RVV codes too much and binutils
supports theadvector.
I have provided the draft approach:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html
which turns out doesn't need
Adding Drew and Robert.
On Sun, Nov 19, 2023 at 10:04 PM juzhe.zh...@rivai.ai
wrote:
> As kito's suggestions. I just have a quick try.
>
> This patch should does following things:
>
> 1. Remove all new API that RVV1.0 doesn't have. E.g. vlb.
> They should be another separate patch to be revi
As kito's suggestions. I just have a quick try.
This patch should does following things:
1. Remove all new API that RVV1.0 doesn't have. E.g. vlb.
They should be another separate patch to be reviewed.
So the first series patch should be "Support part of theadvector API base
on current RV
Currently I start to work on full coverage testing (with different compile
option test GCC testsuite)
and fix bugs which is highest priority definitely.
I am not able to find the time review this patch on GCC-14 for now.
So conservatively, postpone it to GCC-15.
If we are lucky that I stabliz
>> 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.
No. We don't need to add (duplicate) any new patterns.
I know RVV GCC very well. I know how to do that.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-11
>> 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 theadvect
