This is the mail archive of the gcc-bugs@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]

Re: optimization/3384: PowerPC -funroll-loops -fbranch-count-reg misoptimization


> Synopsis: PowerPC -funroll-loops -fbranch-count-reg misoptimization
> 
> Responsible-Changed-From-To: unassigned->mmitchel
> Responsible-Changed-By: dje
> Responsible-Changed-When: Fri Jul 20 10:39:36 2001
> Responsible-Changed-Why:
>     GCC 2.95 regression
> State-Changed-From-To: open->analyzed
> State-Changed-By: dje
> State-Changed-When: Fri Jul 20 10:39:36 2001
> State-Changed-Why:
>     Patch waiting for approval
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3384&database=gcc

Thanks for looking at that, but could you please consider the patch in
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01080.html in favor of this
one?  This improves a tiny bit on normal non-unrolled loops, and it has
some comments.  Also I forgot to remove some misleanding comments in that
patch, so I attach below a comment-only patch that should be applied
after http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01080.html.

Also note that there is still a bug here, that is not new:

main(){unsigned int i; for (i = ~0-39; i < ~0u-1; i += 4);}

This is an infinite loop, but it quits when compiled with -O2.  It would
be easy to fix for the constant limit case, actually I have some hack for
that, but for the variable final value case that would require extra
run-time checks for every loop even if they would never overflow, and the
standard behavior is undefined anyways, so it probably does not worth
fixing it (that was that way even in 2.95).

Thanks,

Zoli

 --- doloop.c	Mon Jul 16 16:10:29 2001
 +++ doloop.c	Fri Jul 20 13:45:10 2001
 @@ -568,15 +568,10 @@
    /* The number of iterations (prior to any loop unrolling) is given by:
       (abs (final - initial) + abs_inc - 1) / abs_inc.
  
 -     However, it is possible for the summation to overflow, and a
 -     safer method is:
 -
 -     abs (final - initial) / abs_inc + (abs (final - initial) % abs_inc) != 0
 -
       If the loop has been unrolled, then the loop body has been
       preconditioned to iterate a multiple of unroll_number times.
       The number of iterations of the loop body is simply:
 -     abs (final - initial) / (abs_inc * unroll_number).
 +     (abs (final - initial) + abs_inc - 1) / (abs_inc * unroll_number).
  
       The division and modulo operations can be avoided by requiring
       that the increment is a power of 2 (precondition_loop_p enforces
 @@ -600,7 +595,7 @@
  
 	if (abs_inc != 1)
 	  {
 -	  /* abs (final - initial + abs_inc - 1) / abs_inc
 +	  /* abs (final - initial + abs_inc - 1) / abs_inc / unroll_number
 	      If we get an overflow, the loop is infinite, and
 	      the loop count is set to zero.  That is not really
 	      infinite but it will run UINT_MAX+1 times */


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