From: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
To: richard.sandiford <richard.sandiford@arm.com>
Cc: rguenther <rguenther@suse.de>,
incarnation.p.lee <incarnation.p.lee@outlook.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
Kito.cheng <kito.cheng@sifive.com>, ams <ams@codesourcery.com>
Subject: Re: Re: [PATCH] RISC-V: Bugfix for mode tieable of the rvv bool types
Date: Mon, 13 Feb 2023 18:39:06 +0800 [thread overview]
Message-ID: <5A5BF6F43016873F+20230213183905364478128@rivai.ai> (raw)
In-Reply-To: <20230213182800944794123@rivai.ai>
[-- Attachment #1: Type: text/plain, Size: 3898 bytes --]
>> Yeah, I am aggree with you. Memory system access should always at least 1-byte.
>> So, consider such following code:
>> vsetvl e8,mf8
>> vlm.v v8, a0 (v8 is a 1-bit mask (Not sure what the behavior dealing with this case))
>> vsm.v v8,a1
>> vsetvl e8,m1
>> vlm.v v8, a0 (v8 is a 8-bit mask)
>> vsm.v v8,a2
>> (Note: both vlm.v are loading same address)
>> Such asm will not happen in GCC. It will become like this since bool modes are tied:
>> vsetvl e8,mf8
>> vlm.v v8, a0 (v8 is a 8-bit mask)
>> vsm.v v8,a0
>> vsm.v v8,a1
>> I am not sure whether it's correct. Maybe I should ask RVV ISA community.
Such case may not be appropriate to talke about. Since 1bit mask for VNx1BI is the minimum value.
Since the size is a poly value (1,1). It can be only be 1 bit or 1bytes or 2bytes...etc. It's a compile-time unknown which is denpending on CPU vector length.
This case should be represent as this:
vsetvl e8,mf8
vlm.v v8, a0 (v8 is a N x 1-bit mask, N is compile-time unknown))
vsm.v v8,a1
vsetvl e8,m1
vlm.v v8, a0 (v8 is a N x 8-bit mask, N is compile-time unknown)
vsm.v v8,a2
(Note: both vlm.v are loading same address)
Such asm will not happen in GCC. It will become like this since bool modes are tied:
vsetvl e8,mf8
vlm.v v8, a0 (v8 is a N x 1-bit mask, N is compile-time unknown))
vsm.v v8,a0
vsm.v v8,a1
Such asm codegen is incorrect, this is what we want to fix.
juzhe.zhong@rivai.ai
From: juzhe.zhong@rivai.ai
Date: 2023-02-13 18:28
To: richard.sandiford
CC: rguenther; incarnation.p.lee; gcc-patches; Kito.cheng; ams
Subject: Re: Re: [PATCH] RISC-V: Bugfix for mode tieable of the rvv bool types
Yeah, I am aggree with you. Memory system access should always at least 1-byte.
So, consider such following code:
vsetvl e8,mf8
vlm.v v8, a0 (v8 is a 1-bit mask (Not sure what the behavior dealing with this case))
vsm.v v8,a1
vsetvl e8,m1
vlm.v v8, a0 (v8 is a 8-bit mask)
vsm.v v8,a2
(Note: both vlm.v are loading same address)
Such asm will not happen in GCC. It will become like this since bool modes are tied:
vsetvl e8,mf8
vlm.v v8, a0 (v8 is a 8-bit mask)
vsm.v v8,a0
vsm.v v8,a1
I am not sure whether it's correct. Maybe I should ask RVV ISA community.
juzhe.zhong@rivai.ai
From: Richard Sandiford
Date: 2023-02-13 18:18
To: juzhe.zhong\@rivai.ai
CC: rguenther; incarnation.p.lee; gcc-patches; Kito.cheng; ams
Subject: Re: [PATCH] RISC-V: Bugfix for mode tieable of the rvv bool types
"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai> writes:
>>> What's the byte size of VNx1BI, expressed as a function of N?
>>> If it's CEIL (N, 8) then we don't have a way of representing that yet.
> N is a poly value.
> RVV like SVE support scalable vector.
> the N is poly (1,1).
>
> VNx1B mode nunits = poly(1,1) units.
> VNx1B mode bitsize =poly (1,1) bitsize.
> VNx1B mode bytesize = poly(1,1) units (currently). Ideally and more accurate, it should be VNx1B mode bytesize =poly (1/8,1/8).
But this would be a fractional bytesize, and like Richard says,
the memory subsystem would always access full bytes. So I think
the bytesize would have to be at least CEIL (N, 8).
> However, it can't represent it like this. GCC consider its bytesize as poly (1,1) bytesize.
Ah, OK. That (making the size N bytes) does seem like a reasonable
workaround, provided that it matches the C types, etc. So the total
amount of padding is 7N bits (I assume at the msb of the type when
viewed as an integer).
I agree that what (IIUC) was discussed upthread works, i.e.:
bytesize = N
bitsize = N * 8 (fixed function of bytesize)
precision = N
nunits = N
unit_size = 1
unit_precision = 1
But target-independent code won't expect this layout, so supporting
it will involve more than just adjusting the parameters.
Thanks,
Richard
next prev parent reply other threads:[~2023-02-13 10:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 8:46 incarnation.p.lee
2023-02-11 13:00 ` juzhe.zhong
2023-02-11 13:06 ` juzhe.zhong
2023-02-13 8:07 ` Richard Biener
2023-02-13 8:19 ` juzhe.zhong
2023-02-13 8:46 ` Richard Biener
2023-02-13 9:04 ` juzhe.zhong
2023-02-13 9:41 ` Richard Sandiford
2023-02-13 9:48 ` Richard Biener
2023-02-13 9:48 ` juzhe.zhong
2023-02-13 10:18 ` Richard Sandiford
2023-02-13 10:28 ` juzhe.zhong
[not found] ` <20230213182800944794123@rivai.ai>
2023-02-13 10:39 ` juzhe.zhong [this message]
2023-02-13 11:00 ` Andrew Stubbs
2023-02-13 15:34 ` 盼 李
2023-02-13 15:47 ` Richard Biener
2023-02-15 15:57 ` 盼 李
2023-02-16 15:17 ` 盼 李
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=5A5BF6F43016873F+20230213183905364478128@rivai.ai \
--to=juzhe.zhong@rivai.ai \
--cc=ams@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=incarnation.p.lee@outlook.com \
--cc=kito.cheng@sifive.com \
--cc=rguenther@suse.de \
--cc=richard.sandiford@arm.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).