public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).