Zdenek Dvorak - Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: Zdenek Dvorak
• To: Christian BRUEL
• Cc: Ian Lance Taylor , Richard Guenther , gcc-patches at gcc dot gnu dot org
• Date: Thu, 15 Feb 2007 12:17:52 +0100
• Subject: Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
• References: <45D42560.2010506@st.com> <20070215093343.GA19299@atrey.karlin.mff.cuni.cz> <45D43AB6.4020709@st.com>

Hello,

This allows to optimize loops like : for (i = start; i <= start+1; i++) ...

•  niter->may_be_zero =   boolean_type_node,

•            iv1->base, iv0->base);

I sort of do not understand why you need this change. fold is (or should be) able to derive that start < start + 1, if the computation is performed in TYPE_OVERFLOW_UNDEFINED type.

fold is currently not doing it in this context. and then I thought that it wasn't needed if it is already trivially known at that point than the count is constant.

if it's cleaner to fix 'fold', I can try to look at it (I'm quite eager to improve dhrystone) unless someone here already knowns exactly where to go in fold_const for that. What do you prefer ?

this simplification seems simple enough, and it might appear in other contexts as well, so I think that in this case, fold is the right place where to fix that. I will check what is the problem (I am somewhat surprised we do not fold this already).

Nevertheless, this looks just wrong. relative_count_iv does not compare the relative values of the bases of the induction variables, hence this would also make you eliminate the the may_be_zero assumptions in cases like

for (i = a + 17; i < a + 5; i++)

which is obviously wrong.

This case is tested just before calling 'number_of_iterations_lt' in 'number_of_iterations_cond ': /* If the loop exits immediately, there is nothing to do. */

If fold succeeds to fold the expression base0 < base1, your patch does not help. If it does not, then this check in number_of_iterations_cond won't succeed, either.

Zdenek

• Follow-Ups:
  • Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
    * From: Christian BRUEL
  • Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
    * From: Christian BRUEL
• References:
  • Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
    * From: Christian BRUEL
  • Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
    * From: Zdenek Dvorak
  • Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv
    * From: Christian BRUEL