[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.

2004-11-14 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15 01:58 --- Now I see what is the difference between this and PR 18431, = vs . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16803

[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.

2004-11-12 Thread nathan at gcc dot gnu dot org
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-12 09:24 --- We cannot generate better code, without having a different meaning for the sign_extend action that occurs in the loop. As zdenek points out, we cannot use dbra, because we cannot tell if the loop will

[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.

2004-11-11 Thread nathan at gcc dot gnu dot org
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-11 17:40 --- FSF HEAD 2004-11-11 gives better code, with the invariants moved out of the loop, .main: ld 9,[EMAIL PROTECTED](2) lwz 11,0(9) addi 11,11,20 extsw 11,11 cmpwi 7,11,0

[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.

2004-11-11 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 18:19 --- Woops I I filed PR 18431 (which I think is the same problem well the testcases are the same), I will note I copied both -m32 and -m64 loops to show where the problem is and with arrays we get much better

[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.

2004-07-30 Thread steven at gcc dot gnu dot org
--- Additional Comments From steven at gcc dot gnu dot org 2004-07-30 17:41 --- I doubt LNO would help here, it looks like a backend issue. But you can give it a try. -- What|Removed |Added