[tuples] Tuplify some passes

[Steven Bosscher]

On Tue, Jun 10, 2008 at 10:01 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 6:46 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On 6/10/08 12:41 PM, Steven Bosscher wrote:
>>
>>> OK to commit after testing completes?
>>
>> Yes.  Thanks for converting these.
>
> The cunroll bits cause a couple of test suite failures (although
> bootstrap completes without trouble).  I'll commit the uncprop part
> and see if I can fix the other bits.

This turns out to be a problem in tree-ssa-loop-niter.c:get_val_for().
 There used to be a fold() call there so that "val = fold (...)" would
always be non-NULL -- fold() just returns the original expression if
there is nothing to fold.  But in the tuplified version, there is "val
= gimple_fold(...)" and gimple_fold() returns NULL if there is nothing
to fold.  So val ends up NULL, get_val_for() returns NULL, and aval[0]
in loop_niter_by_eval() is set to NULL.  Then, fold_binary() is
called, and it crashes on a NULL operand.

I could fix this by just returning chrec_dont_know if get_val_for()
returns NULL.

However, I'm not sure whether we might be missing some loop iteration
computations here.  Before tuples, the complete rhs of two statements
could be passed to fold.  Now we punt if a rhs is not foldable.  So
before tuples, we could find the number of iterations for two
non-foldable rhs if the pair was foldable, and with tuples we would
fail to compute the number of iterations in this case.  At least, if I
understand all this code correctly.  I probably don't, hence Zdenek in
the CC:   :-)

Zdenek, thoughts?
The failing test case is 20000412-6.c on ia64 at -O2, with my patches
from earlier in this thread applied.

Thanks,

Gr.
Steven