From: Xi Ruoyao <xry111@xry111.site>
To: Jiufu Guo <guojiufu@linux.ibm.com>
Cc: gcc-patches@gcc.gnu.org, segher@kernel.crashing.org,
dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com,
rguenther@suse.de, richard.sandiford@arm.com,
jeffreyalaw@gmail.com
Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie
Date: Wed, 14 Jun 2023 17:18:15 +0800 [thread overview]
Message-ID: <6bd54083cadc5d5720afb01f9ab202a2ac748863.camel@xry111.site> (raw)
In-Reply-To: <7nfs6ubyel.fsf@ltcden2-lp1.aus.stglabs.ibm.com>
On Wed, 2023-06-14 at 09:55 +0800, Jiufu Guo wrote:
> Hi,
>
> Xi Ruoyao <xry111@xry111.site> writes:
>
> > On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote:
> >
> > > Compare with previous version, this addes ChangeLog and removes
> > > const_anchor parts.
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621356.html.
> >
> > [Off topic]
> >
> > const_anchor is just broken now. See
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843 and the thread
> > beginning at
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591470.html. If
> > you want to use it for rs6000 I guess you need to fix it first...
>
> Thanks so much for pointing out this. It seems about supporting
> negative value, right?
>
> As you say: for 1. "g(0x8123ffff, 0x81240001)", it would be fine.
>
> The generated insns are:
> (insn 5 2 6 2 (set (reg:DI 117)
> (const_int -2128347135 [0xffffffff81240001])) "negative.c":5:3 681 {*movdi_internal64}
> (nil))
> (insn 6 5 7 2 (set (reg:DI 118)
> (plus:DI (reg:DI 117)
> (const_int -2 [0xfffffffffffffffe]))) "negative.c":5:3 66 {*adddi3}
> (expr_list:REG_EQUAL (const_int -2128347137 [0xffffffff8123ffff])
> (nil)))
>
> While for 2. "g (0x7fffffff, 0x80000001)", the generated rtl insns:
> (insn 5 2 6 2 (set (reg:DI 117)
> (const_int -2147483647 [0xffffffff80000001])) "negative.c":5:3 681 {*movdi_internal64}
> (nil))
> (insn 7 6 8 2 (set (reg:DI 3 3)
> (const_int 2147483647 [0x7fffffff])) "negative.c":5:3 681 {*movdi_internal64}
> (nil))
>
> The current const_anchor does not generate sth like: "r3 = r117 - 2"
> But I would lean to say it is the limitation of current implementation:
> "0xffffffff80000001" and "0x7fffffff" hit different anchors(even these
> two values are 'close' on some aspect.)
The generic issue here is to fix (not "papering over") the signed
overflow, we need to perform the addition in a target machine mode. We
may always use Pmode (IIRC const_anchor was introduced for optimizing
some constant addresses), but can we do better?
Should we try addition in both DImode and SImode for a 64-bit capable
machine?
Or should we even try more operations than addition (for eg bit
operations like xor or shift)? Doing so will need to create a new
target hook for const anchoring, this is the "complete rework" I meant.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
next prev parent reply other threads:[~2023-06-14 9:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 12:23 Jiufu Guo
2023-06-13 12:48 ` Xi Ruoyao
2023-06-14 1:55 ` Jiufu Guo
2023-06-14 9:18 ` Xi Ruoyao [this message]
2023-06-14 15:05 ` Segher Boessenkool
2023-06-15 7:59 ` Jiufu Guo
2023-06-13 18:33 ` Segher Boessenkool
2023-06-14 4:06 ` Jiufu Guo
2023-06-14 7:59 ` Richard Biener
2023-06-14 9:04 ` Richard Sandiford
2023-06-14 9:22 ` Richard Biener
2023-06-14 9:43 ` Richard Sandiford
2023-06-14 9:52 ` Richard Biener
2023-06-14 10:02 ` Richard Sandiford
2023-06-14 16:08 ` Segher Boessenkool
2023-06-14 16:32 ` Segher Boessenkool
2023-06-14 9:29 ` Jiufu Guo
2023-06-14 16:38 ` Segher Boessenkool
2023-06-14 9:26 ` Jiufu Guo
2023-06-14 15:45 ` Segher Boessenkool
2023-06-14 15:38 ` Segher Boessenkool
2023-06-14 16:25 ` Richard Biener
2023-06-14 17:03 ` Segher Boessenkool
2023-06-14 15:15 ` Segher Boessenkool
2023-06-15 7:00 ` Jiufu Guo
2023-06-15 16:30 ` Segher Boessenkool
2023-06-16 2:24 ` Jiufu Guo
-- strict thread matches above, loose matches on Subject: below --
2023-06-12 13:19 Jiufu Guo
2023-06-13 0:24 ` David Edelsohn
2023-06-13 2:15 ` Jiufu Guo
2023-06-13 18:14 ` Segher Boessenkool
2023-06-13 18:59 ` David Edelsohn
2023-06-14 3:00 ` Jiufu Guo
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=6bd54083cadc5d5720afb01f9ab202a2ac748863.camel@xry111.site \
--to=xry111@xry111.site \
--cc=bergner@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=guojiufu@linux.ibm.com \
--cc=jeffreyalaw@gmail.com \
--cc=linkw@gcc.gnu.org \
--cc=rguenther@suse.de \
--cc=richard.sandiford@arm.com \
--cc=segher@kernel.crashing.org \
/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).