From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17100 invoked by alias); 9 May 2006 11:59:32 -0000 Received: (qmail 17071 invoked by uid 48); 9 May 2006 11:59:24 -0000 Date: Tue, 09 May 2006 11:59:00 -0000 Message-ID: <20060509115924.17070.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/22563] [4.0/4.1/4.2 Regression] performance regression for gcc newer than 2.95 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-05/txt/msg00905.txt.bz2 List-Id: ------- Comment #13 from hubicka at gcc dot gnu dot org 2006-05-09 11:59 ------- The simplified testcase seems to be solved now (on mainline and Athlon): hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ gcc-2.95 -O3 t.C -march=i686 hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ ./a.out hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ time ./a.out real 0m1.809s user 0m1.798s sys 0m0.000s hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ time ./a.out real 0m1.841s user 0m1.796s sys 0m0.002s hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ /aux/hubicka/egcs-mainline/bin/g++ -O3 t.C -static -march=i686 hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ time ./a.out real 0m1.713s user 0m1.676s sys 0m0.003s hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ time ./a.out real 0m1.719s user 0m1.700s sys 0m0.000s hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ /aux/hubicka/egcs-mainline/bin/g++ -O3 t.C -static -march=athlon hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ time ./a.out real 0m1.353s user 0m1.347s sys 0m0.002s hubicka@kampanus:/aux/hubicka/gcc/build/gcc$ The assembly looks comparable to 2.95 one (instruction count wise, form is closer to 4.0) .L29: andl $-16, %edx cmpb $80, %dl jne .L27 decl %ecx je .L28 .L18: movl $86, %edx movb $86, b_rec movl %edx, %eax andl $7, %eax cmpb $6, %al je .L29 .L27: call abort Since no direct testcase for code in comment 5 is attached, can I ask if the problem presist with generic model? It looks like the benchmark was executed on different core than i686 but compiled with i686. With generic we should now assume the partial memory stores and thus avoid the integer moves by halves of destination. Honza -- hubicka at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563