So, I found the patch to do_jump_by_parts_greater_rtx() by Eric Botcazou that should address the stupid code and the redundant branch.
Should have done a broader search before I wasted email bandwidth... On Oct 31, 2012, at 1:51 PM, Alan Lehotsky <alehot...@me.com> wrote: > I'm looking at code generated for a new port of gcc using 4.6.1 and failing > execute/950607-2.c with -O0 only > > The target chip has only 32 bit instructions, so it's using > do_jump_by_parts_<relop>_rtx() to expand the compare. > I've set up my .md to use the CCmode. > > I see one case that seems really stupid, and one that's just wrong. I'm > thinking that either I have something really flawed with my port's handing of > DImode or that there was a bug in 4.6.1. The port is only failing about > 2100 dejagnu tests (passing 64000+) and a good chunk of the failures are due > to the ridiculously small data-memory size of the chip. > > For > > long long int x; > > if ( x < 0 ) return 0 else return 2; > > I see code that compares MSBs and branches on < (less than) as expected. But > then it goes and checks the MSBs for != , and finally it checks the LSBS and > emits a conditional branch to the ELSE, followed by an unconditional branch > to the ELSE, so that I end up with code that looks like > > mov $r1,x > mov $r2,x+4 > cmpi $r2,0 > jlt .L5 > cmpi $r2,0 <=== totally redundant for "x < 0" comparisons > jne .L2 > cmpi $r1,0 > jmp .L4 > > .L5 : movi $r1, 0 > jump .L4 > > .L2 : movi $r1, 2 > > .L4: > ret > > > This is a simplification of 950607-2.c, which fails at -O0, but passes at > higher optimization levels (go figure...) >
