[LLVMdev] llvm alloca dependencies

Preston Briggs preston.briggs at gmail.com
Thu Jan 24 09:03:04 PST 2013

> I tried methods related to point 1) suggested by you,
> but I still have problems of finding dependencies.
> What exactly I want to do:
> I have a chain like : Alloca -> Load(1) -> ... -> Computation
> where the variable might be changed -> Store(new_var) -> ... -> Load(n)

Your example is not very clear.
I don't understand what's involved in the "chain".

> Computation where the variable is changed = means that :
> I might have Alloca(a),  c=a+7000*b[32], Load(c)...ICMP(c, ...)
> I want to get the corresponding Alloca from every Load
> (corresponding from the point of view of the variable used,
> meaning that the Load is using a variables based/dependent on the Alloca
or Allocas).

I don't know any magical LLVM way to get all the answers.
My approach would be to do some ordinary data-flow analysis,
chasing back along def-use chains to find instructions that define
the registers used in the load, recursively, to the beginning.
If you hit an alloca, stop.

> I tried to use methods from DependencyAnalysis class.

DependenceAnalysis. Seems like a bad start.
Dependence analysis is used to determine how two
array references may interact. Nothing to do with alloca.

> 1. if (DA.depends(loadInstrArray[i],loadInstrArray[j],false)) - no result

I can't say if this is correct or not without a more complete example.
For instance, in the code

    for (i = 0; i < n; i += 2) {
        loadInstr[i] = 0;
        j = i + 1;
        loadInstr[j] = 1;

there is no dependence between the two stores to loadInstr.
The two stores write entirely disjoint areas of memory.
On the other hand, if we have

    for (i = 0; i < n; i++) {
        loadInstr[i] = 0;
        j = 2*i;
        loadInstr[j] = 1;

we expect to find a more interesting pattern.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130124/ecf72161/attachment.html>

More information about the llvm-dev mailing list