[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From dmixm at marine dot febras dot ru 2004-11-16
23:58 ---
In March, 2004 Richard Sandiford has offered a patch for elimination of
this problem. See: http://gcc.gnu.org/ml/gcc/2004-03/msg01456.html This
patch modifies function do_jump (a file dojump.c). This change now is
present at a branch 4.0, but does not enter in 3.4.x. I have tried to
apply this patch to 3.4.3. It has earned only after change of a line
if (TREE_CODE (TREE_OPERAND (exp, 0)) == RSHIFT_EXPR
...
to
tree arg_nops = TREE_OPERAND (exp, 0); /* and below the same subst. */
STRIP_NOPS (arg_nops);
if (TREE_CODE (arg_nops) == RSHIFT_EXPR
...
and only for function foo_i.
foo_i() before patch:
...
mov r24,r25
ldi r25,6
1: lsr r24
dec r25
brne 1b
sbrs r24,0
rjmp .L2
foo_i() after patch:
...
sbrs r25,6
rjmp .L8
But foo_ll (shift loop with count 62!) and foo_l have remained on old -
through shift of the left argument.
Source file:
~~~
int foo_ll (long long x)
{
return (x 0x4000LL) ? 1 : 3;
}
int foo_l (long x)
{
return (x 0x4000) ? 5 : 7;
}
int foo_i (int x)
{
return (x 0x4000) ? 9 : 11;
}
int foo_c (char x)
{
return (x 0x40) ? 13 : 15;
}
P.S. The code for foo_c was and remains beautiful due to work
`gcc/combine.c' .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-17 07:21 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1 From: dmixm at marine dot febras dot ru [EMAIL PROTECTED] But foo_ll (shift loop with count 62!) and foo_l have remained on old - through shift of the left argument. It would seem in general that if GCC in addition to transforming: ((size)x (size)pow-of-2-value)) = (size)(x log2-value) it also then transformed all RSHIFT expressions of the form: (size)(x value) = (size-lsw)((subreg:(size-lsw) x:size lsw)) (value-(word-size*lsw))) [where lsw is the lest significant pow-of-2 word which remains significant i.e lsw = 0 implies all words remain significant, lsw = 1 implies the precision of the result may be reduced by one word, etc.] It would enable for a hypothetical 8-bit word-wide machine: (4-word-type)(X 0x0400) = (4-word-type)(X 26) = (1-word-type)((subreg:1-word-type X:4-word-type 3) 2) Or for a 16-bit word wide machine: (or analogously for even wider machines) (2-word-type)(X 0x0400) = (2-word-type)(X 26) = (1-word-type)((subreg:1-word-type X:2-word-type 1) 10) Which both enables the use of the resulting demoted precision value to be expressed more optimally as an argument in subsequent expressions, and to more optimally generate code on less-then-word-wide target machines. Furthermore, the subreg representation of demoted expression values, could also enable the potential further optimization of sign/zero extended values, by allowing the detection of only sign or zero extended bits remaining significant: (4-word-type)((char)X (long)0x0400) = (4-word-type)((long-char)X 26) = (1-word-type)((subreg:char ((long-char)x):long 3) 2) = (1-word-type)((subreg:char (sign x):char 3) 2) = (1-word-type)(sign x) Or something like that possibly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 15:51
---
Subject: Re: 3.4.3 ~6x+ performance regression vs.
3.3.1, constant trees not being computed.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
05:04 ---
int_val long_val == (long)(int_val) long_val by what I had quoted in the
other bug which you were
talking about this.
Also, that simplification comes from combine and knowning that ((int_val
long_val) (log2
long_val)) 1 (where long_val MAX_INT) is false (nothing else). The
problem on PPC and this one is
the same. Anyways as I had said before this is not a regression.
For what it's worth, comparable code for ppc (as 23 is within int range):
int foo ( int a ) {
if (a (1L 55))
return 1;
else
return 2;
}
Which I suspect will show a difference, although due to ppc's multi-bit
shift capabilities, it's literal representation may be detectable during
instruction-generation/peep-hole-optimization, but not on machines where
multi-bit shifts are not as compactly represented, therefore rely on earlier
recognition and optimization as appears to be present in 3.3.4.
Regardless of ppc relative code quality, 3.4.3 is generating substantially
slower larger code than 3.3.4 for avr with no corresponding target machine
description changes, therefore would think that 3.4.3 is clearly suffering
from an avr target code performance/quality regression, yes?
As another less dramatic example:
int foo ( long a ) {
if (a (1L 23)) // where again (1L 55) for ppc
return 1;
else
return 2;
}
Also demonstrates 3.4.3's generation of inferior avr code, relative to
3.4.3, with no corresponding changes to it's target description; which
seems to be due to the constant expression (1L 23) not being computed if
nested within a more complex expression, which 3.3.4 was capable of
detecting, but 3.4.3 isn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From joseph at codesourcery dot com 2004-11-11 16:22 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. Have you actually tried compiling code identical to that you test but with 8388608L in place of (1L 23) before making claims about what is done with constant expressions? Your example may suggest a regression, provided no type sizes changed for your target between the versions compared, but you really shouldn't report conjectures about the cause of a bug without clear evidence to substantiate them, which in this case would involve substituting the value of the constant expression in the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From ericw at evcohs dot com 2004-11-11 16:29 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:52 --- or the default for -mint8 changed. The size of long has always stayed at 32 bits. The default sizes for -mint8 *might* have changed. I know that Svein Seldal corrected a problem with the size of long with -mint8, but I thought that was on HEAD, i.e. for 4.0.0, not necessarily on 3.4.3. But I could be wrong. For reference: Normal: char = 8 bits int = 16 bits long = 32 bits With -mint8 (on 4.0.0 IIRC) char = 8 bits int = 8 bits long = 16 bits Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 17:19 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. From: joseph at codesourcery dot com [EMAIL PROTECTED] --- Additional Comments From joseph at codesourcery dot com 2004-11-11 16:22 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. Have you actually tried compiling code identical to that you test but with 8388608L in place of (1L 23) before making claims about what is done with constant expressions? Your example may suggest a regression, provided no type sizes changed for your target between the versions compared, but you really shouldn't report conjectures about the cause of a bug without clear evidence to substantiate them, which in this case would involve substituting the value of the constant expression in the testcase. Good point, will do with both 0x80L and (1 23). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 20:28
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
From: joseph at codesourcery dot com [EMAIL PROTECTED]
--- Additional Comments From joseph at codesourcery dot com 2004-11-11
16:22 ---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
Have you actually tried compiling code identical to that you test but with
8388608L in place of (1L 23) before making claims about what is done
with constant expressions?
Your example may suggest a regression, provided no type sizes changed for
your target between the versions compared, but you really shouldn't report
conjectures about the cause of a bug without clear evidence to
substantiate them, which in this case would involve substituting the value
of the constant expression in the testcase.
You were correct, the problem wasn't that 3.4.3 wasn't computing the
constant expression values, it was that it was oddly transforming constant
values into runtime computed expressions, such that 3.4.3 converted:
(a 0x80L) = ((long)a 23) 1), which doesn't quite seem sensible.
The following are the results for both 3.4.3 and 3.3.1; where 3.4.3 shows a
100x performance regression, and a ~4x size regression relative to 3.3.1:
The source:
/*Compiling: main.c using (for the sake of argument)
avr-gcc -c -mmcu=atmega64 -I. -g -Os -funsigned-char -funsigned-bitfields
-fpack-struct
-fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst
-I/usr/local/avr/include
-std=gnu99 -funsafe-math-optimizations
-Wp,-M,-MP,-MT,main.o,-MF,.dep/main.o.d main.c
-o main.o
Linking: main.elf (again for the sake of argumnet)
avr-gcc -mmcu=atmega64 -I. -g -Os -funsigned-char -funsigned-bitfields
-fpack-struct
-fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o
-I/usr/local/avr/include
-std=gnu99 -funsafe-math-optimizations
-Wp,-M,-MP,-MT,main.o,-MF,.dep/main.elf.d main.o
--output main.elf -Wl,-Map=main.map,--cref-lm
File: main.c
*/
int foo0 ( int a ){
if (a 0x80L)
return 1;
else
return 2 ;
}
int foo1 ( int a ){
if (a (1L 23))
return 1;
else
return 2 ;
}
int foo2 ( long a ){
if (a 0x80L)
return 1;
else
return 2 ;
}
int foo3 ( long a ){
if (a (1L 23))
return 1;
else
return 2 ;
}
int main( void ){
volatile int a;
a = foo0 ( a );
a = foo1 ( a );
a = foo2 ( a );
a = foo3 ( a );
return 0;
}
Listing for 3.4.3
main.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00800100 01c8 025c 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 01c8 0094 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00800100 01c8 025c 2**0
ALLOC
3 .noinit 00800100 00800100 025c 2**0
CONTENTS
4 .eeprom 0081 0081 025c 2**0
CONTENTS
5 .stab 05d0 025c 2**2
CONTENTS, READONLY, DEBUGGING
6 .stabstr 046e 082c 2**0
CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:
__vectors:
0:0c 94 46 00 jmp0x8c
4:0c 94 61 00 jmp0xc2
8:0c 94 61 00 jmp0xc2
c:0c 94 61 00 jmp0xc2
10:0c 94 61 00 jmp0xc2
14:0c 94 61 00 jmp0xc2
18:0c 94 61 00 jmp0xc2
1c:0c 94 61 00 jmp0xc2
20:0c 94 61 00 jmp0xc2
24:0c 94 61 00 jmp0xc2
28:0c 94 61 00 jmp0xc2
2c:0c 94 61 00 jmp0xc2
30:0c 94 61 00 jmp0xc2
34:0c 94 61 00 jmp0xc2
38:0c 94 61 00 jmp0xc2
3c:0c 94 61 00 jmp0xc2
40:0c 94 61 00 jmp0xc2
44:0c 94 61 00 jmp0xc2
48:0c 94 61 00 jmp0xc2
4c:0c 94 61 00 jmp0xc2
50:0c 94 61 00 jmp0xc2
54:0c 94 61 00 jmp0xc2
58:0c 94 61 00 jmp0xc2
5c:0c 94 61 00 jmp0xc2
60:0c 94 61 00 jmp0xc2
64:0c 94 61 00 jmp0xc2
68:0c 94 61 00 jmp0xc2
6c:0c 94 61 00 jmp0xc2
70:0c 94 61 00 jmp0xc2
74:0c 94 61 00 jmp0xc2
78:0c 94 61 00 jmp0xc2
7c:0c 94 61 00 jmp0xc2
80:0c 94 61 00 jmp0xc2
84:0c 94 61 00 jmp0xc2
88:0c 94 61 00 jmp0xc2
008c __ctors_end:
8c:11 24 eorr1, r1
8e:1f be out0x3f, r1; 63
90:cf ef ldi
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
02:48 ---
Here is an example for PPC:
int foo2 ( short a ){
if (a (1 23))
return 1;
else
return 2 ;
}
but it is not a regression on PPC with the above example
--
What|Removed |Added
Severity|critical|minor
Component|c |middle-end
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:49 --- I amost think the size of long changed for 3.4.0 for avr to 32bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:52 --- or the default for -mint8 changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:15
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
Yes but regardless of the size of the constant 1:
if (a (1L 24)) or (a (1 24)) yields the same results,
and further, if a simpler expression containing the same constant
Sub-expression is used, it properly computes the constant expression:
int foo (int a) {
a = a + (1 24); // apparently simple enough to compute (1 24)
if (a (1 24)) {// then utilized here, which yields 0
return 1;
else
return 2;
}
= return 2;
Which implies that it is not a back-end issue, but that (1 24)
is not being calculated as a constant expression if nested within
a more complex expression for some reason, I believe?
although the PPC may have optimized it away in other ways as it has
a more powerful shift instruction, but should not be a back-end thing,
as the embedded constant expression was properly computed and applied
in 3.3.x.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 11 Nov 2004 02:49:28 -
To: [EMAIL PROTECTED]
Subject: [Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1,
constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
02:49 ---
I amost think the size of long changed for 3.4.0 for avr to 32bits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 03:17 --- When I did 1 24 I got a warning (at least on the mainline on a cross to avr) about 24 being greater than the size of int so it was going to be 0. Again in real terms there is something on here but I really doubt it is a regression and you did not use -mint8 for the 3.3 build and not for the 3.4 build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:55
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote:
When I did 1 24 I got a warning (at least on the mainline on a cross to
avr) about 24 being greater
than the size of int so it was going to be 0. Again in real terms there is
something on here but I really
doubt it is a regression and you did not use -mint8 for the 3.3 build and not
for the 3.4 build.
Yes, you're correct, (1 24) generates warnings: (not forcing -mmint8)
main.c: In function `foo1':
main.c:3: warning: left shift count = width of type
main.c: In function `foo2':
main.c:12: warning: left shift count = width of type
main.c: At top level:
main.c:21: warning: return type of 'main' is not `int'
and produces the anticipated correct code, sorry for the confusion.
---
However as reported with (1L 24), it does not, nor should it yield
different results, but it appears to product the expected code only if
the same constant expression occurs in a simpler expression in the same
basic block: ?
File: main.lss:
main.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00800100 011e 01b2 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 011e 0094 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00800100 011e 01b2 2**0
ALLOC
3 .noinit 00800100 00800100 01b2 2**0
CONTENTS
4 .eeprom 0081 0081 01b2 2**0
CONTENTS
5 .stab 04c8 01b4 2**2
CONTENTS, READONLY, DEBUGGING
6 .stabstr 044e 067c 2**0
CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:
__vectors:
0:0c 94 46 00 jmp0x8c
4:0c 94 61 00 jmp0xc2
8:0c 94 61 00 jmp0xc2
c:0c 94 61 00 jmp0xc2
10:0c 94 61 00 jmp0xc2
14:0c 94 61 00 jmp0xc2
18:0c 94 61 00 jmp0xc2
1c:0c 94 61 00 jmp0xc2
20:0c 94 61 00 jmp0xc2
24:0c 94 61 00 jmp0xc2
28:0c 94 61 00 jmp0xc2
2c:0c 94 61 00 jmp0xc2
30:0c 94 61 00 jmp0xc2
34:0c 94 61 00 jmp0xc2
38:0c 94 61 00 jmp0xc2
3c:0c 94 61 00 jmp0xc2
40:0c 94 61 00 jmp0xc2
44:0c 94 61 00 jmp0xc2
48:0c 94 61 00 jmp0xc2
4c:0c 94 61 00 jmp0xc2
50:0c 94 61 00 jmp0xc2
54:0c 94 61 00 jmp0xc2
58:0c 94 61 00 jmp0xc2
5c:0c 94 61 00 jmp0xc2
60:0c 94 61 00 jmp0xc2
64:0c 94 61 00 jmp0xc2
68:0c 94 61 00 jmp0xc2
6c:0c 94 61 00 jmp0xc2
70:0c 94 61 00 jmp0xc2
74:0c 94 61 00 jmp0xc2
78:0c 94 61 00 jmp0xc2
7c:0c 94 61 00 jmp0xc2
80:0c 94 61 00 jmp0xc2
84:0c 94 61 00 jmp0xc2
88:0c 94 61 00 jmp0xc2
008c __ctors_end:
8c:11 24 eorr1, r1
8e:1f be out0x3f, r1; 63
90:cf ef ldir28, 0xFF; 255
92:d0 e1 ldir29, 0x10; 16
94:de bf out0x3e, r29; 62
96:cd bf out0x3d, r28; 61
0098 __do_copy_data:
98:11 e0 ldir17, 0x01; 1
9a:a0 e0 ldir26, 0x00; 0
9c:b1 e0 ldir27, 0x01; 1
9e:ee e1 ldir30, 0x1E; 30
a0:f1 e0 ldir31, 0x01; 1
a2:02 c0 rjmp.+4 ; 0xa8
00a4 .do_copy_data_loop:
a4:05 90 lpmr0, Z+
a6:0d 92 stX+, r0
00a8 .do_copy_data_start:
a8:a0 30 cpir26, 0x00; 0
aa:b1 07 cpcr27, r17
ac:d9 f7 brne.-10 ; 0xa4
00ae __do_clear_bss:
ae:11 e0 ldir17, 0x01; 1
b0:a0 e0 ldir26, 0x00; 0
b2:b1 e0 ldir27, 0x01; 1
b4:01 c0 rjmp.+2 ; 0xb8
00b6 .do_clear_bss_loop:
b6:1d 92 stX+, r1
00b8 .do_clear_bss_start:
b8:a0 30 cpir26, 0x00; 0
ba:b1 07 cpcr27, r17
bc:e1 f7 brne.-8 ; 0xb6
be:0c 94 7c 00 jmp0xf8
00c2 __bad_interrupt:
c2:0c 94 00 00 jmp0x0
00c6 foo1:
int foo1 ( int a ){
if (a (1L 23))
c6:aa 27 eorr26, r26
c8:97 fd sbrcr25, 7
ca:a0 95
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 04:33 --- Subject: Re: 3.4.3 ~6x+ performance regression vs. 3.3.1, constant trees not being computed. As implied earlier, this problem may be related to (in my words) an overly complicated and error prone processes of having to subsequently demote operations and operands after their often needless initial promotion prior to having determined their need. Which longer term should really be re-considered, as it should be understood that is not required to literally follow C's documented evaluation semantics to yield logically equivalent optimal results. As operands need only be promoted if their operation require it as determined by it's targets need, and expression trees could be simplified if integer nodes were tagged with their sign in addition to their size, rather then requiring a cast node be added to the tree, thereby indirectly likely requiring less tree memory, less collections, and simpler rtl target instruction descriptions. The reason that PPC may not see the problem is that the ppc is both an int wide machine, and has a multi-bit shift instruction, which may be optimized away though a different mechanism than is failing in this circumstance. But regardless, the problem exposed in this circumstance is a regression from whatever middle-end mechanism enabled the proper evaluation of the constant expression 3.3.1 which enabled the static analysis of the logical result of the expression at hand, therefore shouldn't be considered a target specific problem. (something broke in 3.3 - 3.4 which isn't insignificant for less than int wide targets without instruction sets similar to ppc.) Thanks again for time and hopeful consideration, -paul- From: Paul Schlie [EMAIL PROTECTED] Date: Wed, 10 Nov 2004 22:55:42 -0500 To: [EMAIL PROTECTED] Subject: Re: [Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: When I did 1 24 I got a warning (at least on the mainline on a cross to avr) about 24 being greater than the size of int so it was going to be 0. Again in real terms there is something on here but I really doubt it is a regression and you did not use -mint8 for the 3.3 build and not for the 3.4 build. Yes, you're correct, (1 24) generates warnings: (not forcing -mmint8) main.c: In function `foo1': main.c:3: warning: left shift count = width of type main.c: In function `foo2': main.c:12: warning: left shift count = width of type main.c: At top level: main.c:21: warning: return type of 'main' is not `int' and produces the anticipated correct code, sorry for the confusion. --- However as reported with (1L 24), it does not, nor should it yield different results, but it appears to product the expected code only if the same constant expression occurs in a simpler expression in the same basic block: ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 04:41 --- Actually what you said is not true for this testcase as you have int long and not int int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 04:59 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED] --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 04:41 --- Actually what you said is not true for this testcase as you have int long and not int int. Sorry, I don't understand, it's fairly apparent to me, and apparently 3.3, and 3.4 (once it's actually does compute (1L 23) in an earlier sub-expression), that: 16-bits-wide-variable = (16-bit-wide variable 0x0100) = 0 ??? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 05:04 --- int_val long_val == (long)(int_val) long_val by what I had quoted in the other bug which you were talking about this. Also, that simplification comes from combine and knowning that ((int_val long_val) (log2 long_val)) 1 (where long_val MAX_INT) is false (nothing else). The problem on PPC and this one is the same. Anyways as I had said before this is not a regression. -- What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-11 05:04:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
