Deterministic iteration over llvm iterators

Forgot cc, the entire group.

How can deterministically iterate over the uses of a variable. i.e. the uses should be any particular order that doesn’t change from execution to execution of the opt tool.

To make myself more clearer, here is a snippet of code that has Values reordered each time I analyze a particular piece of code(which doesn’t change) with the LLVM opt tool and my LLVM pass.

void Anders::id_gep_ce(Value *G){
assert(G);
//Check all GEP and bitcast ConstantExpr’s using G.
for(Value::use_iterator it= G->use_begin(), ie= G->use_end(); it != ie; ++it){
ConstantExpr *E= dyn_cast(*it);
do_something_with(E);
}

i.e. use_begin() and use_end() still works correctly such that iterates through all the uses of G but the uses themselves are reordered. My question is whether I can deterministically iterate through all the uses of G each time run the analysis.

Currently this is what happens in principle:

Execution 1: <val 1> <val 2> <val 3>

Execution 2: <val 2> <val 1> <val 3>

The llvm version that I am using llvm 2.5. My machine is an x86 32 bit dual core machine.

The code that I am analyzing is some bytecode that is generated apriori. This is only generated once, and the analysis reads this particular bytecode file to perform an analysis using the opt tool.

Thanks,
Augustine

Forgot cc, the entire group.

How can deterministically iterate over the uses of a variable. i.e. the uses should be any particular order that doesn't change from execution to execution of the opt tool.

To make myself more clearer, here is a snippet of code that has Values reordered each time I analyze a particular piece of code(which doesn't change) with the LLVM opt tool and my LLVM pass.

use_iterator should be deterministic.

Currently this is what happens in principle:

Execution 1: <val 1> <val 2> <val 3>

Execution 2: <val 2> <val 1> <val 3>

The llvm version that I am using llvm 2.5. My machine is an x86 32 bit dual core machine.

This was a bug in the LLVM 2.5 bitcode reader which has already been fixed, please update to mainline.

-Chris

There is a problem in this area (pr5680). The use order is kept consistent in memory, but writing the IR to a bitcode file causes the order to be lost.

http://llvm.org/bugs/show_bug.cgi?id=5680

I mean SVN head, but it might have been fixed in 2.6 as well, I don’t remember.