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

I am pretty excited about the recent activity on dependence
analysis. The only remaining problem from our point of view
is how to get the alias information to the back end instruction
scheduler. If I understand things correctly, the alias information
basically gets lost in the process of lowering to target
instructions.

We are interested in the DSP domain, so we really need to get
SIMD style parallelism to work, and this needs alias information.
In one of the earlier threads on alias analysis someone commented
that preserving the alias information would not really be that
difficult, but possibly tedious.

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, then one should be able to use those
values and the AliasAnalysis interface to query dependences
between MachineInstr's. I am not intimately familiar with
how the lowering is done, so if there are some obvious
problems with this approach, please let me know.
-- 
Pertti

Hi,
> 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.

Ciao,

Duncan.

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 Apr 2, 2008, at 1:14 AM, Pertti Kellomäki wrote:
> I am pretty excited about the recent activity on dependence
> analysis. The only remaining problem from our point of view
> is how to get the alias information to the back end instruction
> scheduler. If I understand things correctly, the alias information
> basically gets lost in the process of lowering to target
> instructions.
>
> We are interested in the DSP domain, so we really need to get
> SIMD style parallelism to work, and this needs alias information.
If you handle this at LLVM IR level then you've access to all the  
alias info and GEP instructions are directly available to you.  LLVM  
IR supports vector types for SIMD style parallelism and target  
specific code generators lowers them appropriately.

-
Devang
>
> In one of the earlier threads on alias analysis someone commented
> that preserving the alias information would not really be that
> difficult, but possibly tedious.
>
>
> 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, then one should be able to use those
> values and the AliasAnalysis interface to query dependences
> between MachineInstr's. I am not intimately familiar with
> how the lowering is done, so if there are some obvious
> problems with this approach, please let me know.
> -- 
> Pertti
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Devang Patel wrote:
> If you handle this at LLVM IR level then you've access to all the  
> alias info and GEP instructions are directly available to you.  LLVM  
> IR supports vector types for SIMD style parallelism and target  
> specific code generators lowers them appropriately.
Our target is a statically scheduled VLIW style processor,
which may have custom FUs designed by the user. This means
that the instruction scheduler needs to have very detailed
knowledge of the available FUs, latencies, the interconnection
network etc.  The main problem is not exploiting some set of
vector style FUs, but rather packing parallel operations
into wide instructions. We would love to do this at the level
of LLVM IR, but it does not seem to be possible.
-- 
Pertti