Are you analysing sizes in order to perform host<->accelerator memory synchronization?<br><br><div class="gmail_quote">2013/1/9 Sebastian Dreßler <span dir="ltr"><<a href="mailto:dressler@zib.de" target="_blank">dressler@zib.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dmitry,<br>
<div class="im"><br>
On 01/09/2013 03:48 PM, Dmitry Mikushin wrote:<br>
> Hi Sebastian,<br>
><br>
> This kind of analysis is a pretty complex problem in general case.<br>
> Consider, for instance, function "f" has nested calls of other functions<br>
> with "side effects", meaning they could potentially change the contents of<br>
> "in" or "out" indirectly. For this reason, even current state-of-art<br>
> commercial APIs that imply strong data analysis (like OpenACC or HMPP)<br>
> require functions to be free of side effects, because nobody could solve<br>
> this problem well at compile-time.<br>
><br>
<br>
</div>The functions I'm going to analyze are not having side effects (sorry<br>
for not mentioning). Basically, they are enclosed kernels.<br>
<div class="im"><br>
> Depending on the purpose of your question, this may or may not help: in<br>
> comparison to general analysis, LLVM community makes way better progress in<br>
> analysing data access patterns for vectorization and parallelization. In<br>
> this case, particular code regions or loops are considered for matching<br>
> suitable access patterns. For details on vectorization - you can look into<br>
> the work by Nadav Rotem, Hal Finkel et al, the work by Preston Briggs [1],<br>
> for details on polyhedral analysis - the Polly project [2]. These two could<br>
> be extended further with runtime-assisted data analysis, where knowing<br>
> actual values of pointers and index ranges you can also make conclusions<br>
> about read/write modes with respect to particular code regions, like in [3].<br>
><br>
> [1] <a href="https://sites.google.com/site/parallelizationforllvm/" target="_blank">https://sites.google.com/site/parallelizationforllvm/</a><br>
> [2] <a href="http://polly.llvm.org/" target="_blank">http://polly.llvm.org/</a><br>
> [3] <a href="http://kernelgen.org" target="_blank">http://kernelgen.org</a><br>
><br>
<br>
</div>Thank you. At a glance [3] is really helpful, so I'll have a deeper look<br>
onto it. I also know [2] but didn't used it yet, but now I'll "have to" ;)<br>
<br>
Maybe a few sentences regarding the purpose: the goal is to analyze the<br>
sizes of the provided arguments to the function. What I've done so far<br>
is, that I'm able to analyze data structures (C, C++) and mallocs at<br>
run-time by injected LLVM IR code [4]. Currently I'm further extending<br>
it to analyze C++ classes (most things work, include inheritance,<br>
templates, also std::vector and std::map). However, my problem is the<br>
described one, i.e. how to assign the directions in order to correctly<br>
compute data volumes for in and out. One of the first ideas was to use a<br>
kind of configuration file, since the kernel developer knows about the<br>
data directions. But I think this can be done more elegant. Anyway,<br>
based on your answer I'll maybe go back to this idea.<br>
<br>
<br>
Thanks,<br>
Sebastian<br>
<br>
<br>
[4]<br>
<a href="http://opus4.kobv.de/opus4-zib/files/1556/kdv_dressler_steinke_zibreport.pdf" target="_blank">http://opus4.kobv.de/opus4-zib/files/1556/kdv_dressler_steinke_zibreport.pdf</a><br>
<div class="HOEnZb"><div class="h5"><br>
> Hope it helps,<br>
> - D.<br>
><br>
> 2013/1/9 Sebastian Dreßler <<a href="mailto:dressler@zib.de">dressler@zib.de</a>><br>
><br>
>> Hi,<br>
>><br>
>> suppose the following C function declaration:<br>
>><br>
>>     void f(int *in, int *out);<br>
>><br>
>> Now further suppose, that _in_ is an array only read from and _out_ is<br>
>> an array that is only written to.<br>
>><br>
>> Based on this, I was wondering whether there is some already existing<br>
>> LLVM pass (or maybe a part of a pass) that detects those "data<br>
>> directions" for pointers. I'm not quite sure whether e.g. Alias Analysis<br>
>> can provide me this information (I suppose it *cannot*).<br>
>><br>
>><br>
>> Best regards,<br>
>> Sebastian<br>
>><br>
>> --<br>
>> Mit freundlichen Grüßen / Kind regards<br>
>><br>
>> Sebastian Dreßler<br>
>><br>
>> Zuse Institute Berlin (ZIB)<br>
>> Takustraße 7<br>
>> D-14195 Berlin-Dahlem<br>
>> Germany<br>
>><br>
>> <a href="mailto:dressler@zib.de">dressler@zib.de</a><br>
>> Phone: <a href="tel:%2B49%2030%2084185-261" value="+493084185261">+49 30 84185-261</a><br>
>><br>
>> <a href="http://www.zib.de/" target="_blank">http://www.zib.de/</a><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>
--<br>
Mit freundlichen Grüßen / Kind regards<br>
<br>
Sebastian Dreßler<br>
<br>
Zuse Institute Berlin (ZIB)<br>
Takustraße 7<br>
D-14195 Berlin-Dahlem<br>
Germany<br>
<br>
<a href="mailto:dressler@zib.de">dressler@zib.de</a><br>
Phone: <a href="tel:%2B49%2030%2084185-261" value="+493084185261">+49 30 84185-261</a><br>
<br>
<a href="http://www.zib.de/" target="_blank">http://www.zib.de/</a><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>
</div></div></blockquote></div><br>