Hi Timothy,<div><br></div><div>Thanks for quick reply :)</div><div><br></div><div>I disabled inlining in ~/aesop/blank/Makefile. Now function "main" calls function "func1" with two arguments which alias, aesop still goes ahead and parallelize the loop in function "func".</div>
<div>==============</div><div>func1(A, A+1); </div><div>==============</div><div>So, irrespective of whether aesop inlines function func1/func, above call shouldn't have parallelized loop in function "func" (called from func1).</div>
<div><br></div><div>Thanks,</div><div>Rahul</div><div><br></div><div><br></div><div><br></div><div><div class="gmail_quote">On Mon, Mar 11, 2013 at 7:15 PM, Timothy Mattausch Creech <span dir="ltr"><<a href="mailto:tcreech@umd.edu" target="_blank">tcreech@umd.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rahul,<br>
  Thanks for your interest!<br>
<br>
  Our work does not attempt to make any significant contributions to alias analysis, and acts as a client to existing LLVM AA. Furthermore, the options passed to the AESOP frontend scripts are obeyed at compile time, but at link time certain transformations occur unconditionally.<br>

<br>
Here, AESOP has actually thwarted your experiment by performing inlining just before link-time. You can disable this in ~/aesop/blank/Makefile. It does this unconditionally as a standard set of pre passes to help the analysis as much as possible. As a result, AESOP knows that A and B do not alias and is correctly parallelizing here.<br>

<br>
Best,<br>
Tim<br>
<div class="HOEnZb"><div class="h5"><br>
On Mar 11, 2013, at 8:59 AM, Rahul wrote:<br>
<br>
> Hi Timothy,<br>
><br>
> Today I happened to download the code and do some experiments.<br>
> I actually wanted to see how you handle inter-procedure alias analysis.<br>
> So, I set inline threshold to zero and tried out following example<br>
> ===============================================<br>
> #define N 1024<br>
> void func(double *A, double *B)<br>
> {<br>
>   int i;<br>
>   for (i=1; i<N-2; i++) {<br>
>     B[i] = A[i] + i*3;<br>
>   }<br>
> }<br>
><br>
> void func1(double *A, double *B)<br>
> {<br>
>   func(A,B);<br>
> }<br>
><br>
> int main(void)<br>
> {<br>
>   double data[N];<br>
>   double data1[N];<br>
>   double result=0;<br>
>   int i;<br>
><br>
>   for (i=0; i<N; i++) {<br>
>     result += i*3;<br>
>     data[i] = result;<br>
>   }<br>
>   func1(data, data1);<br>
><br>
>   printf(" Data[10] = %lf\n", data[10]);<br>
>   printf("Data1[10] = %lf\n", data1[10]);<br>
><br>
>   return 0;<br>
> }<br>
> ===============================================<br>
> I got following parallalization info after compiling:<br>
><br>
>     Loop main:for.body has a loop carried scalar dependence, hence will not be parallelized<br>
>     Loop func:for.body carries no dependence, hence is being parallelized<br>
><br>
> Since A and B to function "func" are aliases it shouldn't have parallelized.<br>
><br>
> Can you please let me know how you compute dependence ??<br>
><br>
><br>
> Thanks,<br>
> Rahul<br>
><br>
><br>
><br>
> On Sun, Mar 10, 2013 at 7:28 AM, Timothy Mattausch Creech <<a href="mailto:tcreech@umd.edu">tcreech@umd.edu</a>> wrote:<br>
> On Mon, Mar 04, 2013 at 03:01:15PM +0800, 陳韋任 (Wei-Ren Chen) wrote:<br>
> > Hi Timothy,<br>
> ><br>
> > >  We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at<br>

> > ><br>
> > >  <a href="http://aesop.ece.umd.edu" target="_blank">http://aesop.ece.umd.edu</a><br>
> > ><br>
> > > The main components of the released implementation are loop memory dependence analysis and parallel code generation using calls to POSIX threads. Since we currently have only a 2-person development team, we are still on LLVM 3.0, and some of the code could use some cleanup. Still, we hope that the work will be of interest to some.<br>

> ><br>
> >   Do you have data show us that how much parallelization the AESOP can<br>
> > extract from those benchmarks? :)<br>
> ><br>
> > Regards,<br>
> > chenwj<br>
> ><br>
> > --<br>
> > Wei-Ren Chen (陳韋任)<br>
> > Computer Systems Lab, Institute of Information Science,<br>
> > Academia Sinica, Taiwan (R.O.C.)<br>
> > Tel:886-2-2788-3799 #1667<br>
> > Homepage: <a href="http://people.cs.nctu.edu.tw/~chenwj" target="_blank">http://people.cs.nctu.edu.tw/~chenwj</a><br>
><br>
> Hi Wei-Ren,<br>
>   Sorry for the slow response. We're working on a short tech report which will be up on the website in April. This will contain a "results" section, including results from the SPEC benchmarks which we can't include in the source distribution.<br>

><br>
> Briefly, I can say that we get good speedups on some of the NAS and SPEC benchmarks, such as a 3.6x+ speedup on 4 cores on the serial version of NAS "CG" (Fortran), and "lbm" (C) from CPU2006. (These are of course among our best results.)<br>

><br>
> -Tim<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Rahul Patil.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Rahul Patil.
</div>