[LLVMdev] [Polly] Aliasing problems escalation (WAS: Re: [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?)

[Dmitry Mikushin]

Hi Duncan,

Thanks for looking into this!

> (1) Does @__mod_MOD_array have to be externally visible?

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.

> (2) If it does have to be externally visible, maybe LLVM's alias analysis
can be
taught stuff about _gfortran_st_write and friends

> Another possibility is to do link-time optimization

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.

> I think it's completely different at low-level too!

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.

- D.

2013/1/4 Duncan Sands <baldrick at free.fr>

> PS: Another possibility is to do link-time optimization, since at that
> point the
> optimizers are capable of finding out if that global is used anywhere else
> or
> not.
>


2013/1/4 Duncan Sands <baldrick at free.fr>

> Hi Dmitry,
>
>
> > Here's another case, different in high-level, but similar in low-level.
>
> I think it's completely different at low-level too!
>
>
>  When
>
>> Fortran allocatable array is defined in module, its actual dimensions are
>> kept
>> in internal structure. Loads originated from reading these dimensions
>> confuse
>> Polly on any use of this array.
>>
>> Attachments:
>> 1) Sample Fortran source code (to be compiled with and without -DMODULE
>> to see
>> failing and working version, respectively).
>> 2) LLVM IR for both cases right before Polly analysis (initialization loop
>> "array = 2")
>>
>> Below is diff for quick look:
>>
>
> The problem here seems to be:
>
> - at the start of @main the externally visible global variable
> @__mod_MOD_array
> is initialized with explicit values;
> - later, functions like _gfortran_st_write are called, which as far as the
> optimizers know may be modifying the contents of @__mod_MOD_array;
> - thus after these calls the array contents are reloaded.
>
> Remarks:
>
> (1) Does @__mod_MOD_array have to be externally visible?  If you give it
> internal linkage and reoptimize then all of the loads you don't like go
> away.
> It is the Fortran front-end that gives it external linkage, but maybe
> that's
> a bug in the Fortran front-end?
>
> (2) If it does have to be externally visible, maybe LLVM's alias analysis
> can be
> taught stuff about _gfortran_st_write and friends, which I think only
> read/write
> memory via their arguments (so won't be sneakily accessing
> @__mod_MOD_array).
>
> Ciao, Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130104/ab63de3e/attachment.html>