public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53639] x86_64: redundant 64-bit operations on 32-bit integers
Date: Tue, 12 Jun 2012 07:40:00 -0000	[thread overview]
Message-ID: <bug-53639-4-1NN80C3wSz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53639-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-06-12 07:40:26 UTC ---
Created attachment 27606
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27606
gcc48-pr53639.patch

The first problem is that combiner combines:
(insn 9 8 10 2 (parallel [
            (set (reg:SI 74 [ D.1765 ])
                (and:SI (reg/v:SI 60 [ vpn ])
                    (const_int 1023 [0x3ff])))
            (clobber (reg:CC 17 flags))
        ]) pr53639.c:19 378 {*andsi_1}
     (expr_list:REG_UNUSED (reg:CC 17 flags)
        (nil)))

(insn 10 9 11 2 (set (reg:DI 75 [ D.1765 ])
        (zero_extend:DI (reg:SI 74 [ D.1765 ]))) pr53639.c:19 112
{*zero_extendsidi2_rex64}
     (expr_list:REG_DEAD (reg:SI 74 [ D.1765 ])
        (nil)))

into:
(insn 10 9 11 2 (parallel [
            (set (reg:DI 75 [ D.1765 ])
                (and:DI (subreg:DI (reg/v:SI 60 [ vpn ]) 0)
                    (const_int 1023 [0x3ff])))
            (clobber (reg:CC 17 flags))
        ]) pr53639.c:19 377 {*anddi_1}
     (expr_list:REG_UNUSED (reg:CC 17 flags)
        (nil)))
(expand_compound_operation in particular).  But the presence of the DImode
paradoxical subreg leads the RA to do the move in 64-bit rather than 32-bit.

The attached untested patch cures that by splitting *anddi_1 into *andsi_1_zext
so that the zero extension from SImode to DImode is done only on the result of
the and.

The second problem looks like RA decision, initially the SI 59 register (read
from *q) and DI 80 register (zero_extend:DI (reg:SI 59)) are given the eax/rax
register:
      Popping a2(r80,l0)  -- assign reg 0
...
      Popping a5(r59,l0)  -- assign reg 0
but there is also an esi = (reg:SI 59) assignment in another code branch (set
up of parameters for the tail call), so in the end IRA decides to put SI 59
into %esi register, but doesn't reconsider that the corresponding DI 80
register could be very well moved to that register as well:
Assigning 4 to a5r59
Disposition:
    5:r59  l0     4    6:r60  l0     1    4:r62  l0     2    0:r70  l0     0
    3:r72  l0     5    8:r73  l0     4    7:r75  l0     2    1:r78  l0     1
    2:r80  l0     0
Nothing afterwards fixes this up then.  The REE pass does nothing, as the
zero_extend uses different registers (%rax = zext (%esi)), so it doesn't
eliminate the extension, and supposedly because of that other passes don't
consider it worthwhile to rename the regs.


  reply	other threads:[~2012-06-12  7:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 22:49 [Bug target/53639] New: " mikpe at it dot uu.se
2012-06-12  7:40 ` jakub at gcc dot gnu.org [this message]
2012-06-12 10:41 ` [Bug target/53639] " jakub at gcc dot gnu.org
2012-06-12 12:21 ` ubizjak at gmail dot com
2012-06-14 18:27 ` jakub at gcc dot gnu.org
2024-03-28  6:25 ` pinskia at gcc dot gnu.org

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=bug-53639-4-1NN80C3wSz@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).