> Yes, potentially similar for all the other ifs but I didn't check
> all of them.
Thanks and sure thing, will clean up this in v8.
> if (mode != no_mode && mode != last_mode)
> {
This comes from after not the emit part as I mentioned, I am not quit familiar
with this part, as well as if the after part will effect on emit or not.
But I would like to say the if (prev_mode != mode) can be consider as defensive
code from the Backend (aka the consumer of the mode switching framework).
I think it is not good idea to do something based on the mode switching
framework implementation details.
As a hook (interface) provided by mode switch framework, aka RISC-V backend as
the user of mode switching framework. The implementation of hook in RISC-V
Should only follow the sematics, and get rid of any implementation of the
framework itself. Or we may have many implicit dependency across kinds of
components, and may shoot your own leg one day.
Sorry for disturbing and share some of my two cents.
Pan
-----Original Message-----
From: Robin Dapp <rdapp....@gmail.com>
Sent: Thursday, July 27, 2023 4:42 PM
To: Li, Pan2 <pan2...@intel.com>; Kito Cheng <kito.ch...@sifive.com>
Cc: rdapp....@gmail.com; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang,
Yanzhang <yanzhang.w...@intel.com>
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 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 in v8. AFAIK, the optimize_mode_switching
> only check ptr->mode != no_mode before emit, not sure if I missed
> something.
if (mode != no_mode && mode != last_mode)
{
Shouldn't this cover us? I didn't run the testsuite or so but it looks
like it.
Regards
Robin
