------- Comment #14 from ramana dot radhakrishnan at celunite dot com  
2007-11-27 11:00 -------
(In reply to comment #13)
> This patch sometimes confuses loop2_doloop.  On ia64 this prevents use of
> countable loop branch machine idiom (br.cloop).  On the example used in this
> thread loop2_doloop complains:
> 
> Loop 1 is simple:
>   simple exit 5 -> 6
>   infinite if: (expr_list:REG_DEP_TRUE (subreg:SI (and:DI (plus:DI (minus:DI
> (reg:DI 391)
>                     (reg:DI 370 [ ivtmp.16 ]))
>                 (const:DI (plus:DI (symbol_ref:DI ("a") [flags 0x2] <var_decl
> 0x2aaaaabd7000 a>)
>                         (const_int -2 [0xfffffffffffffffe]))))
>             (const_int 1 [0x1])) 0)
>     (nil))       
>   number of iterations: (lshiftrt:DI (plus:DI (minus:DI (reg:DI 392)
>             (reg:DI 370 [ ivtmp.16 ]))
>         (const_int -2 [0xfffffffffffffffe]))
>     (const_int 1 [0x1]))
>   upper bound: -1
> Doloop: Possible infinite iteration case.
> Doloop: The loop is not suitable.
> 
> The "infinite if" condition is:
> ((r391 - r370) + ('a' - 2)) & 1 == 1
> where r370 is &(a[i]) and r391 is len*sizeof(a[0]), so that r391+'a' is
> &a[len].  Of course, such "infinite if" condition is always false, but
> loop2_doloop does not see that.
> 

This is pretty much the case that causes things to go worse even on the private
port I work on after this patch.

Debugging this on ia64 or my port shows the same point at which this detection
fails,  though mine would fail for the SI case rather than the DI case.

The infinite if case is detected in loop_iv.c : iv_number_of_iterations when it
can't simplify the above mentioned expression. I looked through tree-ssa-ivopts
but I can't see how this can get fixed there unless we change it in loop_iv.c . 

I wonder if we could use DF info to recursively figure out the reaching
definition at insn of r391 and r370 and substitute the RHS in this to simplify
this further.  

However whether that effort would be worthwhile depends on the number of such
cases that we detect in any useful benchmark. My guess is that since this is a
pretty normal construct we'd find it in quite a number of loops that are rather
self-respecting.


-- 


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

Reply via email to