asking your advice about bug

[Tobias Grosser]

On 03/02/2014 08:06 PM, Roman Gareev wrote:
>
>>
>> Yes, this would be a 'solution'. However, I am in fact surprised that
>> those variables are NULL at all. Do you have an idea why this is the
>> case? Understanding this would help to understand if the patch you
>> propose is actually the right solution or if it is just hiding a
>> previous bug.
>>
>
> Hi Tobias,
>
> After consideration of almost all the code in gcc/graphite-dependences.c,
> I think that the NULL arguments being passed to compute_deps are
> appropriate
> for loop_level_carries_dependences.

I slowly come to the same conclusion. Thanks a lot for digging deeper 
into this.

> In my opinion, loop_level_carries_dependences uses the following algorithm
> to determine if the loop at the level DEPTH carries dependences:
>
> This function uses compute_deps for finding RAW, WAR and WAW dependences
> of all basic blocks in the body of the given loop. Subsequently, it tries
> to determine presence of these dependences at the given level. I think that it tries to
> find loop-independent
> dependences [1] in carries_deps. Therefore it maps the relation of
> dependences
> to the relation of the corresponding time-stamps and intersects the result
> with the relation
> in which all the inputs before DEPTH occur at the same time as the output,
> and the input
> at DEPTH occurs before output.

Yes, it checks if all dependences are carried by outer loops already. If 
the intersection is not empty, some dependences are carried by the DEPTH 
we currently check and the loop is consequently not parallel.

 > I might be wrong, but I suppose that
> no_source
> dependences are *unnecessary* for this algorithm.

Yes, this analysis is very correct.

In that light, I believe your previous patch is correct. I will review 
it and we can probably commit it. Thanks for working on this!

Tobias