[polly] Memory access based dependency analysis

[Johannes Doerfert]

Regarding the "more freedom" question:
  Every test case with two reductions in one statement suffices here as we
can only handle them with access based dependency modeling (or multiple runs
of the dependency analysis as I did in the beginning).

Regarding my patch roadmap for the near future:
   1) I was hoping to get these two patches in
   2) Then move the reduction and privatization dependency computations to
the wrapped space
   3) Allow more than one reduction per statement

 In between I'd like to get the IslAst patch in and I'm going to propose a
fix for the problems we discussed so far.

I don't think (because of the example I showed you) we can allow anything
more than one reduction per statement without the memory access dependency
patch, thus we need this one before we can move on.

--

Johannes Doerfert
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation


-----Original Message-----
From: Tobias Grosser [mailto:tobias at grosser.es] 
Sent: Tuesday, June 24, 2014 4:22 PM
To: Johannes Doerfert
Cc: llvm-commits at cs.uiuc.edu; 'Sebastian Pop'
Subject: Re: [polly] Memory access based dependency analysis

On 25/06/2014 01:12, Johannes Doerfert wrote:
> I don't think a single reduction in a statement without anything else 
> needs this memory access based dependency tracking.
> However, I found it easier to order the patches this way. Furthermore, 
> the patch which will cause the need for this kind of Analysis is big 
> enough on its own and I don't really see the point in combining them 
> (or changing the order and producing wrong code in between).
>
> So what is the plan now? Do we agree on the need for this patch? Can I 
> commit it now? If so, we should also consider the next patch as it 
> will bring the compilation time back to normal.

So what is the next patch that requires this one? Can you already post it to
the mailing list? My hope is that we can find a patch order that enables us
to enable multi-statement dependences without introducing incorrectness, but
just being very conservatively in the dependences (only detect reductions if
the statement consists purely of reduction dependences). After this is
committed, we can then use a subsequent patch to give the dependence
analysis more freedom.

Another point I am not sure about. Even in case of multi-reduction
statements, is there a test case where per-access dependences will give more
freedom to the scheduler. Or can the increased freedom only be exploited
together with the reduction aware parallel ast generation?

Tobias