This is the mail archive of the
mailing list for the GCC project.
Re: Bad and/or stupid code for DImode compares with gcc 4.6.1
- From: Alan Lehotsky <alehotsky at me dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 31 Oct 2012 14:23:00 -0400
- Subject: Re: Bad and/or stupid code for DImode compares with gcc 4.6.1
- References: <D90579E7-208A-44E3-A876-20C4BA620D0B@me.com>
- Reply-to: apl at alum dot mit dot edu
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 <firstname.lastname@example.org> 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.
> 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
> This is a simplification of 950607-2.c, which fails at -O0, but passes at higher optimization levels (go figure...)