This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] for optimization/10080: Loop unroller nearly useless


Hello,

> > I agree. In fact I am almost sure nothing wrong can happen in this
> > case anyway -- the counts here are always taken mod small power of 2,
> > so subregs should not matter.
> 
> Err, so are you or are you not handling loops like
> 
> 	unsigned int i;
> 	for (i = 0; i != 1; i += 5)
> 	  ...
> 
> which iterates UINT_MAX*4+1 times?  Please tell me you are...

currently this kind of loops is left unoptimized.

> > > This is a very bad attitude to have wrt optimization.
> > > Repeat after me: "We shall always produce correct code!"
> > 
> > this is why I would do it only when specifially asked to by special
> > flag.
> 
> No.
> 
> > IMHO this is much better than either ignoring the border cases
> > silently (as it is done on many places in gcc) or always decreasing
> > effectivity of optimizations due to cases that really do not exist in
> > practice.
> 
> No.  For these cases we should generate two sets of code.  One
> that is optimized for a specific set of assumptions, and another
> that isn't.  E.g.
> 
> 	unsigned int i, b, e, c;
> 	for (i = b; i < e; i += c)
> 	  ...
> 
>     =>
> 
> 	if (b < e && e <= UINT_MAX-c+1)
> 	  // unroll as desired, known that overflow is impossible.
> 	else
> 	  // generate straight copy, known that overflow *will* happen.

Which would lead to code size growth that would also harm performance.

This is my last post to this thread, in order not to prolong it
unnecessarily. I still believe allowing user to say us 'assume I do no
stupidities, so make my code nice&fast' would be a good thing, but I
will do as you wish.

Zdenek


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