Update: in the case discussed in *this* thread, GCC optimization also helps: with -O2 GCC pulls out dimensions loads from loops. Polly still has a problem due to bitcast, but this is another issue.<br><br>- D.<br><br><div class="gmail_quote">
2013/2/10 Dmitry Mikushin <span dir="ltr"><<a href="mailto:dmitry@kernelgen.org" target="_blank">dmitry@kernelgen.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Duncan,<br><br>Got it. So, it looks like in [case] it is really sufficient to have -O1 for GCC to remove loads (not really remove, but rather pull outside of loops, which is sufficient).<br>

<br>And in this case - GCC -O1 does not help.<br>
<br>Still, is the [case] sufficient for you to track the missing GCC's info and make it accessible to LLVM? Meanwhile, I think we will use GCC -O1, however, I guess, it would likely introduce other issues in turn. Oh.<br>


<br>[case] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059313.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059313.html</a><br><br>Thanks,<br>- D.<br><br><div class="gmail_quote">

2013/1/16 Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dmitry,<div><div><br>
<br>
On 15/01/13 22:22, Dmitry Mikushin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Duncan,<br>
<br>
You mean - what happens if DragonEgg is invoked with GCC optimization? I tried<br>
-O3 and -fplugin-arg-dragonegg-llvm-<u></u>ir-optimize=1, but nothing changed.<br>
</blockquote>
<br></div></div>
no, I meant if you run gcc with optimization and don't use dragonegg at all.<br>
If I understand right, your problem is that the LLVM optimizers don't remove<br>
some loads, and this blocks polly.  If the GCC optimizers are able to remove<br>
the loads, then that means that the gcc optimizers have access to some info<br>
that the LLVM optimizers don't have (because removing the loads is invalid<br>
given the information currently in the IR).  We would then have to just have<br>
to teach dragonegg to extract that information and pass it on to the LLVM<br>
optimizers.<br>
<br>
Ciao, Duncan.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- D.<br>
<br>
2013/1/8 Duncan Sands <<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a> <mailto:<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>>><div><div><br>
<br>
    On 04/01/13 15:58, Duncan Sands wrote:<br>
<br>
        PS: Another possibility is to do link-time optimization, since at that<br>
        point the<br>
        optimizers are capable of finding out if that global is used anywhere<br>
        else or<br>
        not.<br>
<br>
<br>
    By the way, do the GCC optimizers get this, i.e. remove the loads?<br>
<br>
    Ciao, Duncan.<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></blockquote></div><br>