Hi Duncan,<br><br>Thanks for looking into this!<br><br>> (1) Does @__mod_MOD_array have to be externally visible?<br><br>Fortran modules by definition share their entire contents with user sites (functions, other modules), unless some module member is explicitly marked private. So, all data coming from modules should be essentially global by default.<br>
<br>> (2) If it does have to be externally visible, maybe LLVM's alias analysis can be<br>
taught stuff about _gfortran_st_write and friends<br><br>> Another possibility is to do link-time optimization<br><br>Right, but this is a limited solution, so is LTO. The parallizing compiler with are developing must be able to handle the general case, otherwise people would never be happy with it.<br>
<br>> I think it's completely different at low-level too!<br><br>I meant these cases are common with respect to unexpected loads. Trying to eliminate them at compile-time using function-specific knowledge may suite only well-known APIs, e.g. C99 math, libgfortran, etc. But for general case this approach leads nowhere. I agree here with Tobi, that runtime analysis injection may help very well, if inserted *after* memory analysis from ISL is available, but *before* Polly starts to drop away invalid SCoPs. This is currently impossible, because ISL only works on valid scopes supplied by Polly. I'm looking for design routes to let ISL work on regions, that are not yet valid SCoPs, but may become valid, if according to memory analysis we are eligible to replace problematic loads with constants.<br>
<br>- D.<br><br><div class="gmail_quote">2013/1/4 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">
<div class="HOEnZb"><div class="h5">PS: Another possibility is to do link-time optimization, since at that point the<br>
optimizers are capable of finding out if that global is used anywhere else or<br>
not.<br></div></div></blockquote><div><br><br><div class="gmail_quote">2013/1/4 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 class="im"><br>
<br>
> Here's another case, different in high-level, but similar in low-level.<br>
<br></div>
I think it's completely different at low-level too!<div class="im"><br>
<br>
 When<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fortran allocatable array is defined in module, its actual dimensions are kept<br>
in internal structure. Loads originated from reading these dimensions confuse<br>
Polly on any use of this array.<br>
<br>
Attachments:<br>
1) Sample Fortran source code (to be compiled with and without -DMODULE to see<br>
failing and working version, respectively).<br>
2) LLVM IR for both cases right before Polly analysis (initialization loop<br>
"array = 2")<br>
<br>
Below is diff for quick look:<br>
</blockquote>
<br></div>
The problem here seems to be:<br>
<br>
- at the start of @main the externally visible global variable @__mod_MOD_array<br>
is initialized with explicit values;<br>
- later, functions like _gfortran_st_write are called, which as far as the<br>
optimizers know may be modifying the contents of @__mod_MOD_array;<br>
- thus after these calls the array contents are reloaded.<br>
<br>
Remarks:<br>
<br>
(1) Does @__mod_MOD_array have to be externally visible?  If you give it<br>
internal linkage and reoptimize then all of the loads you don't like go away.<br>
It is the Fortran front-end that gives it external linkage, but maybe that's<br>
a bug in the Fortran front-end?<br>
<br>
(2) If it does have to be externally visible, maybe LLVM's alias analysis can be<br>
taught stuff about _gfortran_st_write and friends, which I think only read/write<br>
memory via their arguments (so won't be sneakily accessing @__mod_MOD_array).<br>
<br>
Ciao, Duncan.<br>
</blockquote></div><br> </div></div><br>