public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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
 

  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).