[Bug tree-optimization/58553] New: New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[Bug tree-optimization/58553] New: New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[jgreenhalgh at gcc dot gnu.org]

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

            Bug ID: 58553
           Summary: New fail in PASS->FAIL:
                    gcc.c-torture/execute/memcpy-2.c execution on arm and
                    aarch64
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jgreenhalgh at gcc dot gnu.org

Created attachment 30917
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30917&action=edit
Preprocessed source

Jeff's change to the Jump-Threading code here:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01910.html

Introduced a regression for arm and aarch64 in 
gcc.c-torture/execute/memcpy-2.c, such that I now see:

 *** EXIT code
 emu: host signal 0

When executing the testcase on a model with command line:

/work/gcc-clean/build-arm-none-eabi/install/bin/arm-none-eabi-gcc
-B/work/gcc-clean/build-arm-none-eabi/obj/gcc2/gcc/
/work/gcc-clean/src/gcc/gcc/testsuite/gcc.c-torture/execute/memcpy-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O3 -g
-Wa,-mno-warn-deprecated -lm -marm -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=softfp -o
/work/gcc-clean/build-arm-none-eabi/obj/gcc2/gcc/testsuite/gcc/memcpy-2.x
-save-temps

I've attached the preprocessed source and the output from
-fdump-tree-dom1-details

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30918
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30918&action=edit
Output of dom1

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
James.  Look in the .ldist dump.  In particular look at that memset call. 
We're writing off the end of the structure.  Now to walk backwards and figure
out why  :-)

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |58554

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This sounds like bug 58554.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
Andrew.  Yes it does.  I've never looked at the ldist code, but the dump seems
a bit strange:
Analyzing # of iterations of loop 3
  exit condition [1, + , 1](no_overflow) != 96
  bounds on difference of bases: 95 ... 95
  result:
    # of iterations 95, bounded by 95

  __builtin_memset (&MEM[(void *)&u1 + 1B], 97, 96);


So it determined the right iteration count but mucked up the count in the call
to memset ?!?  Weird

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pthaugen at gcc dot gnu.org

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
*** Bug 58554 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

Bug 58553 depends on bug 58554, which changed state.

Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

Bug 58553 depends on bug 58554, which changed state.

Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-09-30
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.  Jeff, the niter code returns the number of latch executions, so adding
one is correct if the memset happens before the latch (the code doesn't try
to distinguish both cases but it now has to, after I removed the restriction
of distributing only exactly loops with a single basic block).

I'll fix it.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testcase that also fails on x86_64:

#define MAX_LENGTH 96
#define SEQUENCE_LENGTH 31

static struct {
  char buf[MAX_LENGTH + 1];
} u1, u2;

extern void abort (void);

int main ()
{
  int i;
  char c;

  u1.buf[0] = '\0';
  for (i = 0, c = 'A'; i < MAX_LENGTH; i++, c++)
    {
      u1.buf[i] = 'a';
      if (c >= 'A' + SEQUENCE_LENGTH)
        c = 'A';
      u2.buf[i] = c;
    }
  if (u1.buf[MAX_LENGTH] != '\0')
    abort ();

  return 0;
}

jump threading rotates the loop in interesting ways.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

Bug 58553 depends on bug 58554, which changed state.

Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Yes, threading is rotating the loop in "interesting" ways -- I was going to
look at that independently of the correctness issue. 

One of the things I've noticed as I've been laying down some infrastructure for
the FSA optimization is much of the work Zdenek did to prevent threading
through loop headers and such isn't working as well as we'd like.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 30 Sep 2013, law at redhat dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
> 
> --- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
> Yes, threading is rotating the loop in "interesting" ways -- I was going to
> look at that independently of the correctness issue. 
> 
> One of the things I've noticed as I've been laying down some infrastructure for
> the FSA optimization is much of the work Zdenek did to prevent threading
> through loop headers and such isn't working as well as we'd like.

The basic rule should be that threading through loop headers is ok
if
  1) it doesn't end up creating loops with multiple entries,
  2) it doesn't effectively unroll the loop, though the size constraints
in the threading cost model should put up a reasonable limit here, but
as we are threading multiple times we eventually ended up peeling N
iterations

1) is most important as we cannot handle loops with multiple entries
at all.  Peeling all loops N times is of course equally bad.

Richard.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Oct  1 07:41:10 2013
New Revision: 203054

URL: http://gcc.gnu.org/viewcvs?rev=203054&root=gcc&view=rev
Log:
2013-10-01  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/58553
    * tree-loop-distribution.c (struct partition_s): Add niter member.
    (classify_partition): Populate niter member for the partition
    and properly identify whether the relevant store happens before
    or after the loop exit.
    (generate_memset_builtin): Use niter member from the partition.
    (generate_memcpy_builtin): Likewise.

    * gcc.dg/torture/pr58553.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr58553.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
Re: Not creating loops with multiple entries, no doubt that's bad.

It would be nice however, to expose loop nesting.  ie, prior to threading it
looks like one bug fugly loop.  A bit of threading can sometimes expose a
reasonable nested loop structure.   I haven't thought much about what
additional updating we'd need for that, but it's in the back of my mind.  Right
now we're supposed to be rejecting these jump threading requests, but some
might be sliding through.

Re: peeling/unrolling.  Given that we don't iterate DOM anymore, there's little
risk of completely peeling/unrolling the loop, except for loops which just
iterate 1-3 times and are relatively small (we do have size growth limits). 
But our heuristics for when to peel vs leave it alone are trivial at best and
could use some significant improvement.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 1 Oct 2013, law at redhat dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
> 
> --- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
> Re: Not creating loops with multiple entries, no doubt that's bad.
> 
> It would be nice however, to expose loop nesting.  ie, prior to threading it
> looks like one bug fugly loop.  A bit of threading can sometimes expose a
> reasonable nested loop structure.

True, still detecting the multiple entry case is important.

>   I haven't thought much about what
> additional updating we'd need for that, but it's in the back of my mind.  Right
> now we're supposed to be rejecting these jump threading requests, but some
> might be sliding through.

The loop machinery can do most of it itself nowadays (remove no longer
existing loops and discover new loops).  But as we are preserving more
and more metadata attached to loops it is important to keep a loop
identifiable by the same loop header, or if that changes, adjust that
loop manually.

Grepping for "fix_loop_structure: removing loop" and
"flow_loops_find: discovered new loop" in the -details dumps can show
suspicious drop-and-rediscover-loop-with-different-header events.

> Re: peeling/unrolling.  Given that we don't iterate DOM anymore, there's little
> risk of completely peeling/unrolling the loop, except for loops which just
> iterate 1-3 times and are relatively small (we do have size growth limits). 
> But our heuristics for when to peel vs leave it alone are trivial at best and
> could use some significant improvement.

Yeah, I think it's a matter of cost model adjustments.

Richard.