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
Hi Robin,
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 needed
28 matches
Mail list logo
