org; juzhe.zh...@rivai.ai; Wang,
Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
> I see, you mean at the beginning of frm_after, we can just return the
> incoming mode as is?
>
> If (CALL_P (insn))
> return mode; // Given we
> I see, you mean at the beginning of frm_after, we can just return the
> incoming mode as is?
>
> If (CALL_P (insn))
> return mode; // Given we aware the mode is DYN_CALL already.
Yes, potentially similar for all the other ifs but I didn't check
all of them.
> Thank and will cleanup this i
: Li, Pan2 ; Kito Cheng
Cc: rdapp@gmail.com; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang,
Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
>> Why do we appear to return a different mode here? We already request
>> FRM_MODE_DYN_CA
Law ; rdapp.gcc
; kito.cheng
Cc: gcc-patches ; Wang, Yanzhang
Subject: RE: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
Thanks Juzhe and Jeff for suggestion. The approach like emit_insn_before_noloc
will result in below ICE here.
../../../.././gcc/libs
>> Why do we appear to return a different mode here? We already request
>> FRM_MODE_DYN_CALL in mode_needed. It looks like in the whole function
>> we do not change the mode so we could just always return the incoming
>> mode?
>
> Because we need to emit 2 insn when meet a call. One before the c
ail.com; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang,
Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
So after thinking about it again - I'm still not really sure
I like treating every function as essentially an fesetround.
There is a r
handling when end bb is CALL.
Pan
From: 钟居哲
Sent: Thursday, July 27, 2023 6:56 AM
To: Jeff Law ; rdapp.gcc ;
kito.cheng ; Li, Pan2
Cc: gcc-patches ; Wang, Yanzhang
Subject: Re: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
Thanks Jeff.
Hi, Pan:
Plz try (insert
Jeff Law
Date: 2023-07-27 06:46
To: 钟居哲; rdapp.gcc; kito.cheng; pan2.li
CC: gcc-patches; yanzhang.wang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
On 7/26/23 16:21, 钟居哲 wrote:
> Hi, Jeff.
>
> insert_insn_end_basic_block is to handle this followi
On 7/26/23 16:21, 钟居哲 wrote:
Hi, Jeff.
insert_insn_end_basic_block is to handle this following case:
bb 1:
...
CALL.>BB_END of bb
bb 2:
vfadd rne
You can see there is no instructions after CALL.
So you we use insert_insn_end_basic_block insert a "frrm" at the end of
the bb 1.
I know
ivai.ai
From: Jeff Law
Date: 2023-07-27 05:40
To: Robin Dapp; Kito Cheng; Li, Pan2
CC: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
On 7/26/23 07:08, Robin Dapp via Gcc-patches wrote:
&g
On 7/26/23 07:08, Robin Dapp via Gcc-patches wrote:
So after thinking about it again - I'm still not really sure
I like treating every function as essentially an fesetround.
There is a reason why fesetround is special. Does LLVM behave
the same way?
But supposing we really, really want it an
> I would like to propose that being focus and moving forward for this
> patch itself, the underlying other RVV floating point API support and
> the RVV instrinsic API fully tests depend on this.
Sorry, I didn't mean to ditch LCM/mode switching. I believe it is doing
a pretty good job and we shou
钟居哲
*Sent:* Wednesday, July 26, 2023 10:18 PM
*To:* rdapp.gcc ; Li, Pan2
*Cc:* rdapp.gcc ; kito.cheng ;
gcc-patches ; Wang, Yanzhang <
yanzhang.w...@intel.com>
*Subject:* Re: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point
dynamic rounding
Explicitly backup and restore for
give up LCM/PRE chance then just backup and restore for
> each intrinsic bindly.
>
>
>
>
> --
>
> juzhe.zh...@rivai.ai
>
>
>
> *From:* Robin Dapp
>
> *Date:* 2023-07-26 21:46
>
> *To:* juzhe.zhong ; Li, Pan2
>
>
Yanzhang<mailto:yanzhang.w...@intel.com>
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
> current llvm didn't do any pre optimization. They always
> backup+restore for each rounding mode intrinsic
I see. There is still the option of lazily restor
ubject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
> current llvm didn't do any pre optimization. They always
> backup+restore for each rounding mode intrinsic
I see. There is still the option of lazily restoring the
(entry) FRM before a function call but n
> CSR write could be expensive, it will flush whole pipeline in some
> RISC-V core implementation…
Hopefully not flush but just sequentialize but yes, it's usually a
performance concern. However if we set the rounding mode to something
else for an intrinsic and then call a function we want to re
CSR write could be expensive, it will flush whole pipeline in some RISC-V
core implementation…
Kito Cheng 於 2023年7月26日 週三，21:57寫道：
> Sorry for late ack on the LLVM part, I can say they are did the same
> model/semantics, it done by our team member too, and I have regular meeting
> with that guy :
Sorry for late ack on the LLVM part, I can say they are did the same
model/semantics, it done by our team member too, and I have regular meeting
with that guy :P
Robin Dapp via Gcc-patches 於 2023年7月26日 週三，21:47寫道：
> > current llvm didn't do any pre optimization. They always
> > backup+restore fo
> current llvm didn't do any pre optimization. They always
> backup+restore for each rounding mode intrinsic
I see. There is still the option of lazily restoring the
(entry) FRM before a function call but not read the FRM
after every call. Do we have any data on how good or bad the
mode-switchi
pp
Cc: Kito Cheng ; rdapp@gmail.com;
gcc-patches@gcc.gnu.org; Wang, Yanzhang
Subject: RE: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
Thanks Robin for comments.
Yes, you can reference this link to compare the difference between gcc and
llvm. And I am trying to unde
, Pan2 ;
rdapp@gmail.com; gcc-patches@gcc.gnu.org; Wang, Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
current llvm didn't do any pre optimization. They always backup+restore for
each rounding mode intrinsic
We should not reference cu
So after thinking about it again - I'm still not really sure
I like treating every function as essentially an fesetround.
There is a reason why fesetround is special. Does LLVM behave
the same way?
But supposing we really, really want it and assuming there's consensus:
+ start_sequence ();
+ e
> The call fesetround could be any function in practice, and we never
> know if that function might use dynamic rounding mode floating point
> operation or not, also we don't know if it will be called fesetround
> or not.
>
> So that's why we want to restore before function call to make sure we
>
special handling in needed
> function for this.
>
> And thank robin again for nits and cleanups, like
> previous/next_nonnote_nondebug_insn_bb.
>
> Pan
>
> -Original Message-
> From: Robin Dapp
> Sent: Tuesday, July 25, 2023 4:38 PM
> To: Li, Pan2 ; gcc-patches@gcc.gnu.org
> Cc
note_nondebug_insn_bb.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, July 25, 2023 4:38 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang,
Yanzhang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-po
Hi Pan,
> Given we have a call, we would like to restore before call and then
> backup frm after call. Looks current mode switching cannot emit insn
> like that, it can only either emit insn before (mostly) or after
> (when NOTE_INSN_BASIC_BLOCK_P). Thus, we try to emit the one after
> call when n
-Original Message-
From: Li, Pan2
Sent: Tuesday, July 25, 2023 1:52 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 ;
Wang, Yanzhang ; rdapp@gmail.com
Subject: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding
From: Pan
From: Pan Li
Update in PATCH v7:
1. Take previous/next_nonnote_nondebug_insn_bb for seeking the insn.
2. Splitting the function in detection and emit when needed.
Original commit logs:
In basic dynamic rounding mode, we simply ignore call instructions and
we would like to take care of call in
29 matches
Mail list logo
