This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: BImode and STORE_VALUE_FLAG


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]