------- 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
