Hi Dan and Others ,<div><br></div><div>I'm newbie to LLVM and Clang ,But has experience on compiler optimization and VM .</div><div>Everyone talking about the LLVM in my organisation so thought of peeking into it and where this discussion is stalled me ... </div>
<div><br></div><div>so i tried to simulate the problem ,which is discussed here .</div><div>vi sample.c </div><div><br></div><div><div>double f(double** p )</div><div>{</div><div> double a,b,c;</div><div> double * x = &a;</div>
<div> double * y = &b;</div><div> double * z = &c;</div><div><br></div><div> *x = 1;</div><div> *y = *x + 2;</div><div> *z = *x + 3;</div><div><br></div><div> return *x+*y+*z;</div><div>}</div><div><br></div>
<div>double ff(double** p )</div><div>{</div><div> double a,b,c;</div><div> double * x = &a;</div><div> double * y = &b;</div><div> double * z = &c;</div><div><br></div><div> *x = 1;</div><div> *y = *x + 2;</div>
<div> *z = *x + 3;</div><div><br></div><div> return *x+*y+*z;</div><div>}</div><div><br></div></div><div>compiled the sample.c .i.e clang sample.c -S -O3 -emit-llvm</div><div>cat sample.s</div><div><div><br></div><div>
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32"</div><div>target triple = "i386-pc-cygwin"</div>
<div><br></div><div>define double @f(double** nocapture %p) nounwind readnone {</div><div> ret double 8.000000e+00</div><div>}</div><div><br></div><div>define double @ff(double** nocapture %p) nounwind readnone {</div><div>
ret double 8.000000e+00</div><div>}</div></div><div><br></div><div>Boom ...BasicAA or TBAA is doing what it suppose to do :) for restrict qualifier too..</div><div><br></div><div>Any lights on this ???</div><div><br></div>
<div>FYI , $ lli --version</div><div>Low Level Virtual Machine (<a href="http://llvm.org/">http://llvm.org/</a>):</div><div> llvm version 3.0</div><div> Optimized build.</div><div> Built Jan 24 2012 (05:48:10).</div><div>
Host: i386-pc-cygwin</div><div> Host CPU: penryn</div><div><br></div><div>Thanks </div><div>~Umesh </div><div><br></div><div><br><div class="gmail_quote">On Fri, Jan 27, 2012 at 12:37 AM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com">gohman@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Jan 24, 2012, at 8:58 PM, Brent Walker wrote:<br>
<br>
> Thank you for your reply. The compromise you describe below, is it a<br>
> compromise in the LLVM back end or in clang? I run into this while<br>
> building a compiler for a small DSL language for which I generate<br>
> functions that receive a context from which they extract a bunch of<br>
> pointers to doubles from which inputs are passed to the function (I<br>
> just used C/clang in my examples to illustrate the problem).<br>
<br>
</div>For restrict-style alias information, the limitation is in LLVM.<br>
<br>
Since you're not using clang, you might be able to use a custom TBAA<br>
type tree instead. TBAA works differently from restrict; it applies<br>
to loads and stores, rather than to pointers. But if you can frame<br>
your aliasing property as a type-oriented property, saying for<br>
example that each array element is a pointer to a distinct type, it<br>
may suffice.<br>
<div class="HOEnZb"><div class="h5"><br>
Dan<br>
<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></div>