From: "Li, Pan2" <pan2.li@intel.com>
To: "Li, Pan2" <pan2.li@intel.com>, Jeff Law <jeffreyalaw@gmail.com>
Cc: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
"Wang, Yanzhang" <yanzhang.wang@intel.com>,
"kito.cheng@gmail.com" <kito.cheng@gmail.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook
Date: Thu, 28 Sep 2023 01:07:04 +0000 [thread overview]
Message-ID: <MW5PR11MB59086F3A4D61B3B18F358428A9C1A@MW5PR11MB5908.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW5PR11MB5908453B9DFB64648F5845A4A9F2A@MW5PR11MB5908.namprd11.prod.outlook.com>
Almost forget about this patch, sorry for disturbing and kindly ping again.
Pan
-----Original Message-----
From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Li, Pan2 via Gcc-patches
Sent: Monday, September 11, 2023 4:37 PM
To: Jeff Law <jeffreyalaw@gmail.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; kito.cheng@gmail.com
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook
Hi Jeff,
Kindly ping for the Patch V2 as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628508.html
Pan
-----Original Message-----
From: Li, Pan2 <pan2.li@intel.com>
Sent: Friday, August 25, 2023 8:45 PM
To: Li, Pan2 <pan2.li@intel.com>; Jeff Law <jeffreyalaw@gmail.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; kito.cheng@gmail.com
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook
Hi Jeff,
> You might also peek at the RTL gcse/pre code which is also LCM based and
> has the same class of problems.
I found a similar approach to take care of this in gcse.cc/pre_edge_insert with some comments as below.
/* We can't insert anything on an abnormal and
critical edge, so we insert the insn at the end of
the previous block. There are several alternatives
detailed in Morgans book P277 (sec 10.5) for
handling this situation. This one is easiest for
now. */
if (eg->flags & EDGE_ABNORMAL)
insert_insn_end_basic_block (index_map[j], bb);
else
{
insn = process_insert_insn (index_map[j]);
insert_insn_on_edge (insn, eg);
}
It looks the insert_insn_end_basic_block is designed to handle the ABNORMAL edge by inserting at end of previous block from the comments.
Pan
-----Original Message-----
From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Li, Pan2 via Gcc-patches
Sent: Thursday, August 24, 2023 12:54 PM
To: Jeff Law <jeffreyalaw@gmail.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; kito.cheng@gmail.com
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook
Thanks Jeff.
> That implies a save/restore pair around the call (possibly optimized so
> that we minimize the number of save/restores). I would have expected
> x86 to already be doing this. But maybe there's some ABI thing around
> mmx vs x86 state that allows it to be avoided....
Very similar to save/restore but optional.
If no static rounding mode instrinsic here, it is unnecessary to add save/restore
pair around the call. I bet mode-switching take care of this already.
Pan
-----Original Message-----
From: Jeff Law <jeffreyalaw@gmail.com>
Sent: Thursday, August 24, 2023 7:27 AM
To: Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; kito.cheng@gmail.com
Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook
On 8/23/23 08:54, Li, Pan2 wrote:
> Thanks Jeff for comments.
>
>> Understood. So the natural question is why does x86/sh not need this
>> for its mode switching? Don't all the same issues exist on those
>> targets as well?
>
> AFAIK, it comes from the different design principle between the risc-v and x86/arm intrinsic API.
> The risc-v rvv FP rounding mode intrinsic API has one abstract level above the insn itself, while
> the x86/arm only indicates the semantics of the insn.
>
> For example, if one vector instruction VFADD doesn't have static rounding mode (aka encoding rm in insn),
> there is no such a intrinsic API contains rounding mode argument in x86/arm. While the risc-v fp
> vector intrinsic will always have static rounding mode API if the frm is honored.
>
> In short, the risc-v intrinsic API is closer to the end-user, while the x86/arm instrinsic API is closer to insn itself.
OK, but I'm still strugging to see how the distinction is important
here. Ultimately there's a state at a call site. We need to make sure
that state from the current function doesn't impact the callee and we
need to make sure that the callee doesn't impact the state in the caller.
That implies a save/restore pair around the call (possibly optimized so
that we minimize the number of save/restores). I would have expected
x86 to already be doing this. But maybe there's some ABI thing around
mmx vs x86 state that allows it to be avoided....
>
> For the rest part, will have a try based on your suggestion soon as I am in the middle of something.
No problem. Get to it when you can. I think it affects you more than
me :-)
jeff
next prev parent reply other threads:[~2023-09-28 1:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-21 7:26 pan2.li
2023-08-21 14:24 ` Jeff Law
2023-08-23 6:03 ` Li, Pan2
2023-08-23 14:25 ` Jeff Law
2023-08-23 14:54 ` Li, Pan2
2023-08-23 23:26 ` Jeff Law
2023-08-24 4:53 ` Li, Pan2
2023-08-25 12:44 ` Li, Pan2
2023-09-11 8:36 ` Li, Pan2
2023-09-28 1:07 ` Li, Pan2 [this message]
2023-09-29 20:29 ` Jeff Law
2023-09-29 20:49 ` Jeff Law
2023-10-02 8:26 ` Robin Dapp
2023-10-05 11:51 ` Li, Pan2
2023-08-26 13:36 ` [PATCH v2] " pan2.li
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=MW5PR11MB59086F3A4D61B3B18F358428A9C1A@MW5PR11MB5908.namprd11.prod.outlook.com \
--to=pan2.li@intel.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@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).