[Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion

[Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion

[miyuki at gcc dot gnu.org]

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

            Bug ID: 67607
           Summary: Failure to perform constant folding through type
                    conversion
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---

This code is taken from PR67606:

$ cat pr67606.c
int f(int a[], int length)
{
  int count=0;
  for (int i = 0 ; i < length ; i++)
    if (a[i] > 5)
      count++;

  return count;
}

$ g++ -S -O3 -fno-tree-vectorize pr67606.c -fverbose-asm -fdump-tree-optimized

We get:

  <bb 3>:
  ivtmp.6_1 = (unsigned long) a_7(D);
  _19 = (unsigned int) length_4(D);
  _18 = _19 + 4294967295;
  _21 = (sizetype) _18;
  _22 = _21 + 1;
  _23 = _22 * 4;
  _24 = a_7(D) + _23;
  _25 = (unsigned long) _24;

And this leads to generating some redundant code:

  leal    -1(%rsi), %eax  #, tmp114
  leaq    4(%rdi,%rax,4), %rcx    #, tmp111

[Bug tree-optimization/67607] Failure to perform constant folding through type conversion

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
In general, for unsigned x, 1+(unsigned long)(x-1) can be simplified to x only
if we know that x!=0, so we would need VRP information.

Maybe this could be handled as part of the type-promotion work. VRP could tell
that _21+1 can be computed in type unsigned int, and swap the operation and the
conversion. Or it could tell that _19-1 can be computed in type unsigned long,
it doesn't matter much which one it picks. The simplification -1+1 would then
be trivial.

Last idea would be to try and avoid generating so many +1 and -1 in the first
place.

[Bug tree-optimization/67607] Failure to perform constant folding through type conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-09-17
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
so this is

  ((unsigned long)((unsigned int) length_4(D) - 1U) + 1)

you can't optimize this to (unsigned long) length_4(D) as for
length_4 == 0 the result is 0x100000000.

So what's the missed constant folding?  Ah, so the above is guarded with

  if (length_4(D) > 0)

which means we fail to optimize this to (unsigned long)length_4(D) because
we don't consider this transform might be valid when taking into account
range-info.

  # RANGE [1, 2147483647] NONZERO 2147483647
  _19 = (unsigned int) length_4(D);
  # RANGE [0, 2147483646] NONZERO 2147483647
  _18 = _19 + 4294967295;
  # RANGE [0, 2147483646] NONZERO 2147483647
  _21 = (sizetype) _18;
  # RANGE [1, 2147483647] NONZERO 2147483647
  _22 = _21 + 1;

so here VRP could for example have promoted _19 and _18 to sizetype.  Or
it could handle the arithmetic simplification itself.  We'd like to handle

  (T)(X +- CST1) +- CST1

generally here (both widening/shortening casts).

[Bug tree-optimization/67607] Failure to perform constant folding through type conversion

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 36362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36362&action=edit
shortening

The shortening case seems much easier and does not require VRP information.

Calling get_range_info from match.pd is not done now (not sure if it would be a
good idea or not), so the widening case may have to be written separately in
VRP.