This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: BImode and STORE_VALUE_FLAG
- From: "Paulo Matos" <pmatos at broadcom dot com>
- To: "Mikael Pettersson" <mikpe at it dot uu dot se>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 8 May 2013 13:43:02 +0000
- Subject: RE: BImode and STORE_VALUE_FLAG
- References: <19EB96622A777C4AB91610E763265F461C522A at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <20868 dot 59398 dot 251606 dot 991253 at pilspetsen dot it dot uu dot se>
> -----Original Message-----
> From: Mikael Pettersson [mailto:mikpe@it.uu.se]
> Sent: 04 May 2013 11:51
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: BImode and STORE_VALUE_FLAG
>
> I can't comment on the code in question, but the backend for m68k may be
> affected
> since it defines STORE_FLAG_VALUE as -1. Do you have a testcase that would
> cause
> wrong code, or a patch to cure the issue? I'd be happy to do some testing on
> m68k-linux.
>
Mikael,
Still related to this issue, I think I found a bug that affects m68k due to the use of STORE_FLAG_VALUE != 1.
Try the following example (this is a trimmed down version of vector-compare-1.c from gcc testsuite):
int main (int argc, char *argv[]) {
int i, ires;
volatile int i0 = 2;
volatile int i1 = 2;
ires = (i0 >= i1);
if (ires != (i0 >= i1 ? -1 : 0)) {
__builtin_printf ("%i != ((" "%i" " " ">=" " " "%i" " ? -1 : 0) ", (ires), (i0), (i1));
return 1;
}
return 0;
}
I haven't tried to run it in m68k-linux since I don't have binutils-m68k installed but I assume it will print something like:
-1 != ((2 >= 2 ? -1 : 0)
and return exit code 1.
I did run m68k cc1 (gcc-4.7.3) and dumped logs and found the problem (which matches what I am seeing with my port).
We get to vrp1 with:
D.1392_5 = i0.0D.1390_3 >= i1.1D.1391_4;
iresD.1386_6 = (intD.1) D.1392_5;
# VUSE <.MEMD.1405_18>
i0.3D.1394_7 ={v} i0D.1387;
# VUSE <.MEMD.1405_18>
i1.4D.1395_8 ={v} i1D.1388;
if (i0.3D.1394_7 >= i1.4D.1395_8)
goto <bb 4>;
else
goto <bb 3>;
# SUCC: 4 [50.0%] (true,exec) 3 [50.0%] (false,exec)
# BLOCK 3 freq:5000
# PRED: 2 [50.0%] (false,exec)
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:10000
# PRED: 2 [50.0%] (true,exec) 3 [100.0%] (fallthru,exec)
# iftmp.2D.1393_1 = PHI <-1(2), 0(3)>
if (iftmp.2D.1393_1 != iresD.1386_6)
goto <bb 5>;
else
goto <bb 6>;
# SUCC: 5 [62.2%] (true,exec) 6 [37.8%] (false,exec)
The important bits are:
D.1392_5 = i0.0D.1390_3 >= i1.1D.1391_4;
iresD.1386_6 = (intD.1) D.1392_5;
...
# iftmp.2D.1393_1 = PHI <-1(2), 0(3)>
if (iftmp.2D.1393_1 != iresD.1386_6)
goto <bb 5>;
else
goto <bb 6>;
vrp1 will then proceed to find the ranges for D.1392_5 = i0.0D.1390_3 >= i1.1D.1391_4;
Since this is a comparison set_value_range_to_truthvalue is called and returns the range [0, 1].
Then vrp1 simplifies the phi node to iftmp.2D.1393_1 = PHI < 0 > since -1 is not within the range.
From hereon a couple of simplifications break the remainder of the cgraph and generates incorrect code.
Can you reproduce this?
Cheers,
Paulo Matos