On 24/01/16 09:04, Richard Biener wrote:
> On January 23, 2016 7:44:23 PM GMT+01:00, Sebastian Pop <sebpop@gmail.com> wrote:
>> On Sat, Jan 23, 2016 at 12:28 PM, Tom de Vries <Tom_deVries@mentor.com>
>> wrote:
>>> That was my original patch, and Richard commented: 'I think avoiding
>> a NULL
>>> access_fns is ok but it should be done unconditionally, not only for
>> the
>>> DECL_P case'. In order words, he asked me to do the exact opposite of
>> the
>>> change you now propose.
>>>
>>
>> In the case of a DECL_P it is correct to say that it has an access
>> function of 0.
>> In the graphite testcase it is not correct to say that the access
>> function for a given data reference is zero:
>> we only initialize access_fns in the case of a polynomial chrec:
>>
>>   if (TREE_CODE (ref) == MEM_REF)
>>     {
>>       op = TREE_OPERAND (ref, 0);
>>       access_fn = analyze_scalar_evolution (loop, op);
>>       access_fn = instantiate_scev (before_loop, loop, access_fn);
>>       if (TREE_CODE (access_fn) == POLYNOMIAL_CHREC)
>>         {
>> [...]
>>            access_fns.safe_push (access_fn);
>>         }
>>     }
>>
>> In all other cases we may not have a representation of the access
>> functions.
>> It is incorrect to initialize to "A[0]" all those data references that
>> cannot be analyzed.
>
> But does it matter as the base will not be equal with one that can be analyzed?
>

I'd like to propose a different fix.

I think the root cause of the problem is as follows:

The semantics of DDR_ARE_DEPENDENT is:
...
when "ARE_DEPENDENT == NULL_TREE", there exist a dependence
relation between A and B, and the description of this relation
is given in the SUBSCRIPTS array
...

When A and B have DR_NUM_DIMENSIONS == 0, 
initialize_data_dependence_relation can create a ddr with 
DDR_NUM_SUBSCRIPTS == 0, and in the case of our test-case, it does.

I think this is the root cause: initialize_data_dependence_relation 
creates a ddr with DDR_ARE_DEPENDENT (ddr) == NULL_TREE and 
DDR_NUM_SUBSCRIPTS (ddr) == 0, which violates the semantics of 
DDR_ARE_DEPENDENT (ddr) == NULL_TREE.

[ There is the case of non-loop dependence analysis (tested for by 
loop_nest.exists ()), where DR_NUM_DIMENSIONS == 0 for all data 
references, that seems to be an exception. ]

The patch fixes the root cause of the problem by handling 
DR_NUM_DIMENSIONS == 0 in initialize_data_dependence_relation.

OK for trunk, 5.0, 4.9, if bootstrap/reg-test succeeds?

Thanks,
- Tom