Re: [patch] for PRs 27639 and 26719

[Daniel Berlin <dberlin at dberlin dot org>]

Zdenek Dvorak wrote:
> Hello,
> 
>>> The other smaller changes are:
>>> -- the mostly unrelated code to determine whether chrec is growing or
>>>    decreasing was split from scev_probably_wraps_p to a separate function
>>> -- the code testing for used_in_pointer_arithmetic_p in
>>>    scev_probably_wraps_p was removed; the reason is that it
>>>    unfortunately this code is not correct -- even if we assume that the
>>>    arithmetics used in the statements for the
>>>    used_in_pointer_arithmetic_p is true does not wrap (which is a bit
>>>    doubtful, because these statements do not necessarily have to come
>>>    from the expansion of pointer arithmetics),it still does not say
>>>    anything about the operands of these statements (that may be wrapping
>>>    induction variables). 
>> You say it is incorrect without real details.
>> The code (which i believe seb wrote) was built to answer questions about
>> variables, not statements.
>> Looking at it, it checks whether every use of a variable is either
>> casted to a pointer, or an operand to a statement whose lhs is a pointer.
>>
>> IIRC, the basic pattern it was trying to match occurred *everywhere* we
>> had non-global array references, indexing into passed in
>> arrays/pointers, or pointer arithmetic.
>>
>> I.E.
>> foo[i][j] would generate something like:
>>
>>
>> idxtemp = i * 50;
>> idxtemp2 = j + idxtemp;
>> idxtemp3 = (int) foo;  (or was it &foo)
>> idxtemp4 = idxtemp3 + idxtemp2;
>> pointer = (int *)idxtemp4;
> 
> do you have a testcase where not matching this pattern causes us to miss
> some optimizations and could you please create a PR for this? 

I will find one.   There were also some common cases where the *iv* was
directly casted to a pointer, then added to the current pointer.

This caused us to not be able to determine number of iterations in the
loop for those loops, without the above code.

I'll find the testcases and add it to a PR.

> The best
> solution I know about was
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html (what is its
> status, anyway?),

Still bug fixing, i've gotten back to it in the past week.

> but this might be considered too intrusive for stage 3;
It definitely is.

> perhaps we can come up with some special-case handling for the meantime.
Let me get you some testcases so you can see if it's possible.