[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.

["schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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 <schlie@comcast.net>
> Date: Wed, 10 Nov 2004 22:55:42 -0500
> To: <gcc-bugzilla@gcc.gnu.org>
> 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 <gcc-bugzilla@gcc.gnu.org> 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