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

[Duncan Sands]

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.