[Bug tree-optimization/51783] New: Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[Bug tree-optimization/51783] New: Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

             Bug #: 51783
           Summary: Missed optimization for X ==/!= (signed type)
                    ((unsigned type) Y + Z)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ktietz@gcc.gnu.org
            Target: *-*-*


Hi,

for the following example shows the missed optimization

extern int ar[256];

int foo (int x, int y, unsigned int z)
{
  int c = (int) ((unsigned int) x + z);
  return y == c;
}

We produce in 4.7 for -O2 the following optimized gimple tree:

;; Function foo (foo, funcdef_no=0, decl_uid=1601, cgraph_uid=0)

foo (int x, int y, unsigned int z)
{
  int c;
  _Bool D.2717;
  int D.2716;
  unsigned int D.2715;
  unsigned int x.0;

<bb 2>:
  x.0_2 = (unsigned int) x_1(D);
  D.2715_4 = z_3(D) + x.0_2;
  c_5 = (int) D.2715_4;
  D.2717_7 = y_6(D) == c_5;
  D.2716_8 = (int) D.2717_7;
  return D.2716_8;

}

But we could expect in this case:

;; Function foo (foo, funcdef_no=0, decl_uid=1710, cgraph_uid=0)

foo (int x, int y, unsigned int z)
{
  int D.1720;
  int c;
  _Bool D.1717;
  int D.1716;

<bb 2>:
  D.1720_10 = (int) z_3(D);
  c_5 = x_1(D) + D.1720_10;
  D.1717_7 = y_6(D) == c_5;
  D.1716_8 = (int) D.1717_7;
  return D.1716_8;

}

[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-07 18:25:19 UTC ---
I think that would be an invalid transformation except when -fwrapv is used.
The reason is:
  x.0_2 = (unsigned int) x_1(D);
  D.2715_4 = z_3(D) + x.0_2;  <--- wrapping semantics
  c_5 = (int) D.2715_4;

While:
  D.1720_10 = (int) z_3(D);
  c_5 = x_1(D) + D.1720_10;

Was undefined semantics for overflow.  This cannot happen until we have signed
operations which also have wrapping semantics.

[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

--- Comment #2 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-07 18:55:05 UTC ---
Well, IMHO it is still valid in the case of argument of ne/eq comparison, as
indeed here sign and wrap-around doesn't matter.

[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-07 18:57:52 UTC ---
(In reply to comment #2)
> Well, IMHO it is still valid in the case of argument of ne/eq comparison, as
> indeed here sign and wrap-around doesn't matter.

Maybe for this exact IR but what happens if someone later on used c somewhere
else?  Anyways I don't think this is a missed optimization at all because the
code produced will be the same as PLUS_EXPR for both unsigned and signed int
types will be expanded the same.  The only thing that is removed is the cast
which is a nop here.

[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-07 19:04:13 UTC ---
Hmm, here I disagree.  See other ==/!= comparison missed optimization.

Eg for 'x == (signed type)((unsigned type) x + z)' the transformation is
profitable, as it allows later on reduction in comparison.
This transformation leads to 'x == x + (int) z', which can be later on
transformed to 'z == 0'.

[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem with the conversion that is suggested here is the addition if
changed into a signed type might have an undefined behavior when it comes to an
overflow.

It does not matter if it is used later with equals, it is undefined at the
point of addition.

if we change how GCC's gimple IR works where we have a PLUS which has a
wrapping behavior or undefined overflow behavior, then this will just simplify
to that.  There has been some talk about that in the past but it did not get
that far the last time it was started.