On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zh...@rivai.ai wrote:
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can wait until stage1 is
open.
That also works for me. We can always stack them up on a vendor branch
for a few months until things re-open.
Is it a good idea ? I don't want to make RVV support in GCC stop here since
LLVM already has
all RVV support and GCC is far behind LLVM for a long time in case of RVV.
Yes, please don't stop ;). It's really important work!
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2022-11-29 02:02
To: jeffreyalaw
CC: juzhe.zhong; gcc-patches; Kito Cheng
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote:
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong <juzhe.zh...@rivai.ai>
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
* config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
(ENTRY): Adapt for attributes.
(enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): New function.
* config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes.
* config/riscv/riscv.cc (ENTRY): Ditto.
* config/riscv/vector.md (false,true): Add attributes.
I'm tempted to push this into the next stage1 given its arrival after
stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.
I'm also on the fence here: the RISC-V V implementation is a huge
feature so it's a bit awkward to land it this late in the release, but
on the flip side it's a very important feature. It's complicated enough
that whatever our first release is will probably be a mess, so I'd
prefer to just get that pain out of the way sooner rather than later.
There's no V hardware availiable now and nothing concretely announced so
any users are probably going to be pretty advanced, but having at least
the basics of V in there will allow us to kick the tires on the rest of
the stack a lot more easily.
There's obviously risk to taking something this late in the process. We
don't have anything else that triggers the vectorizer, so I think it
should be seperable enough that risk is manageable.
Not sure if Kito wants to chim in, though.
I'm curious about the model you're using. Is it going to be something
similar to mode switching? That's the first mental model that comes to
mind. Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG. Never in a million years would I have expected we'd be
considering reusing that code.
Jeff
