Deterministic iteration over llvm iterators

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Deterministic iteration over llvm iterators

Augustine Mathews
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<ConstantExpr>(*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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Deterministic iteration over llvm iterators

Chris Lattner-2

On Jan 26, 2010, at 7:23 AM, Augustine Mathews wrote:

> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Deterministic iteration over llvm iterators

Bob Wilson-3
In reply to this post by Augustine Mathews
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

On Jan 26, 2010, at 7:23 AM, Augustine Mathews wrote:

> 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<ConstantExpr>(*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
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Deterministic iteration over llvm iterators

Chris Lattner-2
In reply to this post by Chris Lattner-2
I mean SVN head, but it might have been fixed in 2.6 as well, I don't remember.

On Jan 25, 2010, at 2:47 PM, Augustine Mathews wrote:

Thanks chris.

Do you mean llvm 2.6 when you say mainline or something else?

Augustine

On Mon, Jan 25, 2010 at 4:27 PM, Chris Lattner <[hidden email]> wrote:

On Jan 26, 2010, at 7:23 AM, Augustine Mathews wrote:

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




--
Augustine Mathew


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev