llvm dev - Apr 2008 - [LLVMdev] Alias analysis and instruction level parallelism

Duncan Sands wrote:
>> My initial reaction is that if one were to decorate MachineInstr's
>> with the LLVM level pointer values that they use for reading
>> and writing memory,
> 
> this is already the case: SrcValue and SVOffset.
Ah, that's right. I went back and read the discussion from
January, and Florian Brandner explains there that the real
culprit is the lowering of GEP in the codegen prepare pass.

Florian, if you have worked more on this, we would be very interested
in your work. Serialization caused by memory references is a big
obstacle for us at the moment.
-- 
Pertti

On Wednesday 02 April 2008 11:54:26 Pertti Kellomäki
wrote:
> Ah, that's right. I went back and read the discussion from
> January, and Florian Brandner explains there that the real
> culprit is the lowering of GEP in the codegen prepare pass.
codgenprepare rewrites GEP instructions into a sequence of PtrToInt casts, 
additions, multiplies and finally a IntToPtr cast. The basic alias analysis 
pass does not analyse pointers past an IntToPtr cast, and thus returns "may
alias".

i have tried to overcome this. basically you only need to find the base object 
of the original GEP, but this is possible in some simple cases only. if 
pointer arithmetic is involved it is hard to distinguish between the GEP base 
and other calculations. you might even end up analyzing pointer calculations 
that did not originate from a GEP.

an other option would be to save the GEP instructions and provide a mapping 
between them and the lowered arithmetic. it's not very clean but it would be
safe, and probably work well.

florian

Florian Brandner wrote:
> an other option would be to save the GEP instructions and provide a mapping
> between them and the lowered arithmetic. it's not very clean but it
would be
> safe, and probably work well.
In my opinion this seems like the obvious way to go. The information
is already there, so reverse engineering it back does not sound too
clever. Of course if the reverse engineering would provide useful
information about pointers that do not originate from GEP instructions,
then it might be worthwhile. But my feeling is that at least for our
purposes, GEPs really are the interesting stuff. My understanding is
that parallelizing C compilers try to convert pointer arithmetic back
to array access in order to make sense of them, so essentially turning
them into GEPs. Certainly the dependence literature is heavily array
based.
-- 
Pertti