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
