public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations
Date: Wed, 11 Jan 2012 22:57:00 -0000	[thread overview]
Message-ID: <bug-51821-4-MaTIH4MraD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-51821-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2012-01-11 22:54:34 UTC ---
(In reply to comment #8)
> It looks like target issue after all. I'm preparing a patch with following

OTOH, if the pattern says that it outputs to DImode pair (i.e. %eax/%edx, then
the whole pair is clobbered, no matter if any separate register is later used
or not. Due to this rationale, %edx should not be allocated and the patch from
comment #8 only papers over real problem.

To illustrate this problem further, following test clobbers %eax:

--cut here--
unsigned int  __attribute__((noinline))
test (int shift_size)
{
  unsigned long long res = ~0;

  res <<= shift_size;

  return res >> 32;
}
--cut here--

(insn 7 22 20 2 (parallel [
            (set (reg:DI 0 ax [65])
                (ashift:DI (const_int -1 [0xffffffffffffffff])
                    (reg:QI 2 cx [orig:63 shift_size ] [63])))
            (clobber (reg:CC 17 flags))
        ]) t.c:8 489 {*ashldi3_doubleword}
     (expr_list:REG_DEAD (reg:QI 2 cx [orig:63 shift_size ] [63])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (expr_list:REG_UNUSED (reg:SI 0 ax)
                (expr_list:REG_EQUAL (ashift:DI (const_int -1
[0xffffffffffffffff])
                        (subreg:QI (reg/v:SI 2 cx [orig:63 shift_size ] [63])
0))
                    (nil))))))

peephole2 pass allocates SImode ax register as scratch:

(insn 31 30 32 2 (parallel [
            (set (reg:SI 0 ax)
                (const_int 0 [0]))
            (clobber (reg:CC 17 flags))
        ]) t.c:8 -1
     (nil))

(insn 32 31 33 2 (set (reg:CCZ 17 flags)
        (compare:CCZ (and:QI (reg:QI 2 cx [orig:63 shift_size ] [63])
                (const_int 32 [0x20]))
            (const_int 0 [0]))) t.c:8 -1
     (nil))

(insn 33 32 34 2 (set (reg:SI 1 dx [+4 ])
        (if_then_else:SI (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (reg:SI 0 ax [65])
            (reg:SI 1 dx [+4 ]))) t.c:8 -1
     (nil))

(insn 34 33 20 2 (set (reg:SI 0 ax [65])
        (if_then_else:SI (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (reg:SI 0 ax)
            (reg:SI 0 ax [65]))) t.c:8 -1
     (nil))

I'll speculate that (expr_list:REG_UNUSED (reg:SI 0 ax)) plays critical role
here.  Please compare this with (expr_list:REG_UNUSED (reg:SI 1 dx)) in the
pre-peephole2 pattern in Comment #4.


  parent reply	other threads:[~2012-01-11 22:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11 11:02 [Bug c/51821] New: " nos.utelsystems at gmail dot com
2012-01-11 11:21 ` [Bug c/51821] [4.5/4.6/4.7 Regression] " rguenth at gcc dot gnu.org
2012-01-11 11:28 ` [Bug target/51821] " rguenth at gcc dot gnu.org
2012-01-11 12:34 ` ubizjak at gmail dot com
2012-01-11 13:13 ` ubizjak at gmail dot com
2012-01-11 13:21 ` [Bug rtl-optimization/51821] " ubizjak at gmail dot com
2012-01-11 14:15 ` ubizjak at gmail dot com
2012-01-11 22:03 ` ebotcazou at gcc dot gnu.org
2012-01-11 22:35 ` ubizjak at gmail dot com
2012-01-11 22:57 ` ubizjak at gmail dot com [this message]
2012-01-12  7:44 ` ebotcazou at gcc dot gnu.org
2012-01-12  8:04 ` ubizjak at gmail dot com
2012-01-12 11:18 ` ebotcazou at gcc dot gnu.org
2012-01-12 11:35 ` ubizjak at gmail dot com
2012-01-12 11:42 ` ubizjak at gmail dot com
2012-01-12 13:20 ` ebotcazou at gcc dot gnu.org
2012-01-12 17:01 ` ubizjak at gmail dot com
2012-01-12 17:36 ` ubizjak at gmail dot com
2012-01-12 19:18 ` ubizjak at gmail dot com
2012-01-15 18:45 ` uros at gcc dot gnu.org
2012-01-15 20:02 ` uros at gcc dot gnu.org
2012-01-15 20:38 ` uros at gcc dot gnu.org
2012-01-15 21:01 ` uros at gcc dot gnu.org
2012-01-15 21:14 ` ubizjak at gmail dot com

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-51821-4-MaTIH4MraD@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).