[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" <gcc-bugzilla at gcc dot gnu dot org>]

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.