<div dir="ltr"><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Thank you very much for your explanations and suggestions.</font></div><div><font face="courier new, monospace">I'm sorry that I have provided some wrong information last time: llc is (probably?) not able to optimize such code either.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">I tried something more according to the suggestions. Here are the results: (using the same core code shown in the last email)</font></div>
<div><font face="courier new, monospace">1. compile to object file (clang -O3 -c test.c) : good code quality</font></div><div><font face="courier new, monospace">2. compile to bitcode file (clang -O3 -c test.c -emit-llvm) : good</font></div>
<div><font face="courier new, monospace">3. compile to bitcode file (clang -O0 -c test.c -emit-llvm) : bad, similar IR as I wrote manually</font></div><div><font face="courier new, monospace">4. opt test.bc file in step 3 (opt -O3 test.bc) : bad</font></div>
<div><font face="courier new, monospace">5. compile to assembly, from test.bc in step 3 (llc -O3 test.bc) : bad</font></div><div><font face="courier new, monospace">6. IR creation source, from test.bc in step 3 (llc -O3 -march=cpp test.bc) : bad, similar IR as I wrote manually</font></div>
<div><font face="courier new, monospace">7. JIT or MCJIT the source in step 6 (modify and call jit/mcjit) : bad</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">In short, once the source is converted to bad bitcode (or equivalent IR creation), I cannot optimize it back to the -O3 quality.</font></div>
<div><font face="courier new, monospace">What can be the reason? Did the bitcode file lose some high level information, so that certain optimizations are limited?</font></div><div><font face="courier new, monospace">If so, is it possible to reconstruct some naive metadata to enable such optimization? (just for this piece of code, as it is the most important scenario in my project)</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Any help will/would be appreciated.</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace">The source of test.c</font></div><div><font face="courier new, monospace">---------------------------------------------------------------------------------------</font></div>
<div><font face="courier new, monospace">#include <stdio.h></font></div><div><font face="courier new, monospace">#include <stdlib.h></font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">struct S {</font></div>
<div><font face="courier new, monospace"> long long a[10];</font></div><div><font face="courier new, monospace">} *p;</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">void foo () {</font></div>
<div><font face="courier new, monospace"> p->a[2] = p->a[1];</font></div><div><font face="courier new, monospace"> p->a[3] = p->a[1];</font></div><div><font face="courier new, monospace"> p->a[4] = p->a[2];</font></div>
<div><font face="courier new, monospace"> p->a[5] = p->a[4];</font></div><div><font face="courier new, monospace">}</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">int main() {</font></div>
<div><font face="courier new, monospace"> p = (struct S*) malloc(sizeof(struct S));</font></div><div><font face="courier new, monospace"> p->a[1] = rand();</font></div><div><font face="courier new, monospace"> foo();</font></div>
<div><font face="courier new, monospace"> printf("%lld\n", p->a[5]);</font></div><div><font face="courier new, monospace"> return 0;</font></div><div><font face="courier new, monospace">}</font></div>
<div><font face="courier new, monospace">---------------------------------------------------------------------------------------</font></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/21 Richard Osborne <span dir="ltr"><<a href="mailto:richard@xmos.com" target="_blank">richard@xmos.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><div class="im">
<div>On 20 Aug 2013, at 08:23, ÍõÕñ½ <<a href="mailto:cryst216@gmail.com" target="_blank">cryst216@gmail.com</a>> wrote:</div>
<blockquote type="cite">
<div dir="ltr">
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">A GlobalValue was declared and mapped to the variable p.</font></div>
<div><font face="courier new, monospace">Some LLVM IR instructions were created according to those generated by LLVM from source.</font></div>
<div><font face="courier new, monospace">I.e., load p, load a[1] based on p, load p again, store a[2] based on p, etc.</font></div>
<div><font face="courier new, monospace">The machine code turned out to be slightly optmized, as shown on the left.</font></div>
</div>
</blockquote>
<br></div>
I suspect this is due to possible aliasing. If p somehow pointed to itself then the store p->a[x] might change the value of of p so p must be reloaded each time. Clang will emit TBAA metadata nodes (<a href="http://llvm.org/docs/LangRef.html#tbaa-metadata" target="_blank">http://llvm.org/docs/LangRef.html#tbaa-metadata</a>)
that let the optimizers know the load of p can't alias the stores through p since they are have different high-level types. Without the TBAA metadata the optimizers must be conservative.</div>
<div><br>
</div>
<div><div class="im">
<blockquote type="cite">
<div dir="ltr">
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">Things were getting better after the GlobalVariable of p was set as a constant.</font></div>
<div><font face="courier new, monospace">Redundant Loads of p (line 5, 8 and 11) were removed, and so was line 12 because of line 10.</font></div>
</div>
</blockquote>
<br></div>
This makes sense - if p is constant no store can possibly change the value of p so it doesn't need to be reloaded.</div>
<div><div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div><font face="courier new, monospace">However, I could not make it better any more, although optimal machine code just need those marked with '*'.</font></div>
</div>
</blockquote>
</div><div>This is strange, I'm not what sure what is going on here - assuming you are running the same passes I'd expect no difference here.</div>
</div>
</div>
</blockquote></div><br></div></div>