From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-234712-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30713 invoked by alias); 8 Nov 2007 21:45:40 -0000
Received: (qmail 30362 invoked by uid 48); 8 Nov 2007 21:45:30 -0000
Date: Thu, 08 Nov 2007 21:45:00 -0000
Message-ID: <20071108214530.30361.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-34027-9876@http.gcc.gnu.org/bugzilla/>
Subject: [Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled
In-Reply-To: <bug-34027-9876@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-11/txt/msg00749.txt.bz2



------- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-08 21:45 -------
Confirmed.

Also, on 64bit x86_64 we don't see that this computes the modulus, but do

foobar:
.LFB2:  
        movl    $1000000000, %esi
        movq    %rdi, %rax
        xorl    %edx, %edx
        divq    %rsi
        imulq   $-1000000000, %rax, %rax
        addq    %rdi, %rax
        ret

for

unsigned long long foobar(unsigned long long ns)
{
  return ns % 1000000000L;
}

we produce instead

foobar2:
.LFB3:  
        movl    $1000000000, %edx
        movq    %rdi, %rax
        movq    %rdx, %rcx
        xorl    %edx, %edx
        divq    %rcx
        movq    %rdx, %rax
        ret

which is smaller and faster.  Likewise the 32bit variant:

foobar2:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        pushl   $0
        pushl   $1000000000
        pushl   12(%ebp)
        pushl   8(%ebp)
        call    __umoddi3
        addl    $16, %esp
        leave
        ret

which would make this argument moot (ok, only by cheating ;)).  The problem
is supposedly that we don't fold

(chrec_apply
  (varying_loop = 1
)
  (chrec = {ns_2(D), +, 0x0ffffffffc4653600}_1)
  (x = ns_2(D) /[fl] 1000000000)
  (res = ns_2(D) + (ns_2(D) /[fl] 1000000000) * 0x0ffffffffc4653600))

which is ns_2 - (ns_2 / 1000000000) * 1000000000.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
  BugsThisDependsOn|                            |32044
             Status|UNCONFIRMED                 |NEW
          Component|c                           |tree-optimization
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2007-11-08 21:45:30
               date|                            |
   Target Milestone|---                         |4.3.0


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