public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Li, Pan2" <pan2.li@intel.com>
To: Robin Dapp <rdapp.gcc@gmail.com>, Kito Cheng <kito.cheng@sifive.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
	"Wang, Yanzhang" <yanzhang.wang@intel.com>
Subject: RE: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding
Date: Thu, 27 Jul 2023 10:27:57 +0000	[thread overview]
Message-ID: <MW5PR11MB5908625EF3DEBCA602EEF264A901A@MW5PR11MB5908.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4fa1f366-95cb-d846-7afc-bedcf84ffcad@gmail.com>

> 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.gcc@gmail.com> 
Sent: Thursday, July 27, 2023 4:42 PM
To: Li, Pan2 <pan2.li@intel.com>; Kito Cheng <kito.cheng@sifive.com>
Cc: rdapp.gcc@gmail.com; gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@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


  reply	other threads:[~2023-07-27 10:28 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  3:28 [PATCH v1] " pan2.li
2023-07-19  3:31 ` juzhe.zhong
2023-07-19  6:30   ` Li, Pan2
2023-07-20  6:43 ` [PATCH v4] " pan2.li
2023-07-20  6:47   ` juzhe.zhong
2023-07-21  3:11   ` juzhe.zhong
2023-07-21  6:44     ` Li, Pan2
2023-07-23 13:11 ` [PATCH v5] " pan2.li
2023-07-24  0:53   ` juzhe.zhong
2023-07-24  1:51     ` Li, Pan2
2023-07-24  2:45       ` Li, Pan2
2023-07-24  2:42 ` [PATCH v6] " pan2.li
2023-07-24 10:28   ` Robin Dapp
2023-07-24 11:59     ` Li, Pan2
2023-07-24 12:03       ` Li, Pan2
2023-07-25  5:51 ` [PATCH v7] " pan2.li
2023-07-25  6:07   ` Li, Pan2
2023-07-25  8:38     ` Robin Dapp
2023-07-25 11:53       ` Li, Pan2
2023-07-25 13:23         ` Kito Cheng
2023-07-25 14:12           ` Robin Dapp
2023-07-26 13:08             ` Robin Dapp
2023-07-26 21:40               ` Jeff Law
2023-07-26 22:21                 ` 钟居哲
2023-07-26 22:46                   ` Jeff Law
2023-07-26 22:56                     ` 钟居哲
2023-07-27  1:38                       ` Li, Pan2
2023-07-27  8:19                         ` Li, Pan2
2023-07-27  2:09               ` Li, Pan2
2023-07-27  7:25                 ` Robin Dapp
2023-07-27  8:26                   ` Li, Pan2
2023-07-27  8:41                     ` Robin Dapp
2023-07-27 10:27                       ` Li, Pan2 [this message]
     [not found]             ` <63471C6E126E44CF+D1CEA4C9-0050-43CD-8DE3-26EBD7AEE6DA@rivai.ai>
2023-07-26 13:35               ` Li, Pan2
2023-07-26 13:43                 ` Li, Pan2
2023-07-26 13:46               ` Robin Dapp
2023-07-26 13:57                 ` Kito Cheng
2023-07-26 14:05                   ` Kito Cheng
2023-07-26 14:10                     ` Robin Dapp
2023-07-26 14:18                 ` 钟居哲
2023-07-26 14:30                   ` Li, Pan2
2023-07-26 15:34                     ` Kito Cheng
2023-07-26 16:00                       ` Palmer Dabbelt
2023-07-26 21:01                     ` Robin Dapp
2023-07-28  1:15 ` [PATCH v8] " pan2.li
2023-07-28 10:05   ` Robin Dapp
2023-07-28 12:34     ` Li, Pan2
2023-08-01  7:50       ` Kito Cheng
2023-08-01  8:00         ` Li, Pan2

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=MW5PR11MB5908625EF3DEBCA602EEF264A901A@MW5PR11MB5908.namprd11.prod.outlook.com \
    --to=pan2.li@intel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@sifive.com \
    --cc=rdapp.gcc@gmail.com \
    --cc=yanzhang.wang@intel.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).