From: Palmer Dabbelt <palmer@dabbelt.com>
To: jeffreyalaw@gmail.com
Cc: juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org,
Kito Cheng <kito.cheng@gmail.com>
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Date: Mon, 28 Nov 2022 10:02:12 -0800 (PST) [thread overview]
Message-ID: <mhng-ad4af1a7-99cd-4f1b-bdf9-af83f5d1a1c8@palmer-ri-x1c9a> (raw)
In-Reply-To: <ed0bd050-73b4-b31a-434f-c9e5a04e2e66@gmail.com>
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreyalaw@gmail.com wrote:
>
> On 11/28/22 07:14, juzhe.zhong@rivai.ai wrote:
>> From: Ju-Zhe Zhong <juzhe.zhong@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
next prev parent reply other threads:[~2022-11-28 18:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 14:14 juzhe.zhong
2022-11-28 16:44 ` Jeff Law
2022-11-28 18:02 ` Palmer Dabbelt [this message]
2022-11-28 23:10 ` 钟居哲
2022-11-28 23:14 ` Palmer Dabbelt
2022-11-28 22:52 ` 钟居哲
2022-11-28 23:54 ` Jeff Law
2022-11-29 1:38 ` Kito Cheng
2022-11-29 1:46 ` juzhe.zhong
2022-11-29 2:56 ` Palmer Dabbelt
2022-11-29 3:07 ` juzhe.zhong
2022-11-29 3:11 ` Palmer Dabbelt
2022-11-29 4:49 ` Jeff Law
2022-11-29 5:21 ` Palmer Dabbelt
2022-11-29 8:54 ` Kito Cheng
2022-12-01 16:05 ` Kito Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mhng-ad4af1a7-99cd-4f1b-bdf9-af83f5d1a1c8@palmer-ri-x1c9a \
--to=palmer@dabbelt.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).