<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 9:31 AM, Kai Wang via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the reply.<div><br></div><div>Yes I'm doing static analysis. I'm trying to do points-to analysis actually. I care about whether pointer values point to the same memory location. I'm not sure if this is better to be done by Clang or LLVM?</div></div></blockquote><div><br></div><div>That depends on what interface your analysis is going to expose. If the users of your pointer analysis are other IR passes, LLVM IR sounds a better place and you don't need to care about variable names or assignments. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>How to dump the unoptimized IR? By compiling with -O0?</div><div>Thank you.</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 8:20 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you're trying to do source level analysis (questions like "is there an assignment of a variable of this name") it may be better to work up in Clang than down in LLVM - LLVM has no guarantees about names (indeed names on instructions are a compiler debugging feature, not a feature that should be used by any optimization, analysis, etc) or preservation of things like loads/stores.<br><br>You could dump the unoptimized IR, if you're just trying to do some static analysis rather than an optimization - doesn't matter to you, probably, if it doesn't produce a valid kernel in the end.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Feb 9, 2016 at 8:09 AM, Kai Wang via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">
<p><span>Hi all,</span></p><p>I'm compiling linux kernel with clang. I want to generate IR with no optimization. However, kernel can only be compile with -O2 instead of -O0.</p><p>Here is the source code snippet: </p><p><span>struct</span><span> zone *next_zone(</span><span>struct</span><span> zone *zone)</span></p><p><span> </span><span>{ </span>pg_data_t *<b>pgdat</b> = zone->zone_pgdat;</p><p>}</p><p>I want to know there is an assignment from "zone" to "pgdat". I'm trying to iterate "store" instructions in IR. </p><p><span>When I compile with -O2, I have the following IR:</span></p><p><span>define %struct.zone* @next_zone(%struct.zone* readonly %zone) #0 !dbg !</span><span>214</span><span> {</span></p>
<p><span> </span><span>call</span><span> void @llvm.dbg.</span><span>value</span><span>(metadata %struct.zone* %zone, i64 </span><span>0</span><span>, metadata !</span><span>218</span><span>, metadata !</span><span>305</span><span>), !dbg !</span><span>326</span></p>
<p><span> </span><span>%1 = getelementptr inbounds %struct.zone, %struct.zone* %zone, i64 </span><span>0</span><span>, i32 </span><span>5</span><span>, !dbg !</span><span>327</span></p>
<p><span> </span><span>%2 = load %struct.pglist_data*, %struct.pglist_data** %1, align </span><span>8</span><span>, !dbg !</span><span>327</span></p>
<p><span> </span><span>call</span><span> void @llvm.dbg.</span><span>value</span><span>(metadata %struct.pglist_data* %2, i64 </span><span>0</span><span>, metadata !</span><span>219</span><span>, metadata !</span><span>305</span><span>), !dbg !</span><span>328 }</span></p><p><b>Store instruction has been optimized, and no variable name in IR.</b></p><p><span>When I comile with -O0, I have the following IR:</span></p><p><span>define %struct.zone* @</span><span>next_zone</span><span>(%struct.zone* %zone) #0 !dbg !</span><span>211</span><span> {</span></p><p><span> %1 = alloca %struct.zone*, align </span><span>8</span></p><p><span> %pgdat = alloca %struct.pglist_data*, align </span><span>8</span></p><p><span>
</span></p><p><span> store %struct.zone* %zone, %struct.zone** %1, align </span><span>8</span></p><p><span><b> </b>call</span><span> void @llvm.dbg.declare(metadata %struct.zone** %1, metadata !</span><span>297</span><span>, metadata !</span><span>265</span><span>), !dbg !</span><span>298</span></p><p><span>
</span></p><p><span> call</span><span> void @llvm.dbg.declare(metadata %struct.pglist_data** %pgdat, metadata !</span><span>299</span><span>, metadata !</span><span>265</span><span>), !dbg !</span><span>302</span></p><p><span> </span><span>%2 = load %struct.zone*, %struct.zone** %1, align </span><span>8</span><span>, !dbg !</span><span>303</span></p>
<p><span> %3 = getelementptr inbounds %struct.zone, %struct.zone* %2, i32 </span><span>0</span><span>, i32 </span><span>5</span><span>, !dbg !</span><span>304</span></p><p><span> %4 = load %struct.pglist_data*, %struct.pglist_data** %3, align </span><span>8</span><span>, !dbg !</span><span>304</span></p><p><span>
</span></p><p><span> <b>store %struct.pglist_data* %4, %struct.pglist_data** %</b></span><b><span>pgdat</span><span>, align </span><span>8</span><span>, !dbg !</span><span>302</span></b></p><div>There is store instruction. I know there is an assignment. From this store, I backward traverse until I find variable.</div><div>For example, I go through %4->%3->%2->%1->struct.zone. I have variable name pgdat in IR as well.</div><div><br></div><div>Since kernel can only be compiled with -O2, IR has been optimized a lot.</div><div>Is there any way I can know the variable name and there is an assignment from "zone" to "pgdat"?</div><div><br></div><div>Thank you!</div><span><font color="#888888">-- <br><div><div dir="ltr">Regards,<div>Kai</div></div></div>
</font></span></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Regards,<div>Kai</div></div></div>
</font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>