[LLVMdev] how to get a deterministic execution

[dan mihai]

The generated code is deterministic, but the global order the instructions were generated 
seems it is not (although the result is guaranteed to be the same). 
Now I think the order functions are processed might not be guaranteed.
I've attached a test case, and here is what I get:
...............................
 (303)$ ~/bin/llvm/bin/gcc -O3 -emit-llvm try_calls_basic.2.c -c -o try_calls_basic2.bc
 (304)$  $LLVM/opt  -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello  -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x1
 (305)$  $LLVM/opt  -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello  -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x2
 (306)$ diff x1 x2|more
237c237
<       %0 = tail call i32 (...)* %pf() nounwind                ; <i32> [#uses=0] {vuid=69}
---
>       %0 = tail call i32 (...)* %pf() nounwind                ; <i32> [#uses=0] {vuid=56}
....................................
(The -IR-DUMP :ALL is a debugging option I use, that dumps the IR after each function pass  in FPPassManager::runOnFunction)

The vuid are different (69!=56). 
In fact a closer examination shows that the 56-th Value in the first case is 
an instruction in main, while in the 2nd case is an instruction in a different function.

My particular issue is that I want to see when the following instruction is created:
    %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*)        ; <i32 (...)*> [#uses=2] {vuid=67}

So, I assume it is the 67-th Value, set a conditional breakpoint and restart the program. 
But this fails, because the second time it is the 55-th value created:
    %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*)        ; <i32 (...)*> [#uses=2] {vuid=55}


The issues seems to go away, if I remove all other functions from the file and only keep the function I am interested in.

Thank you,
Daniel


> Date: Tue, 19 May 2009 10:59:35 -0700
> From: isanbard at gmail.com
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] how to get a deterministic execution
> 
> On Mon, May 18, 2009 at 8:33 PM, dan mihai <dnmh68 at hotmail.com> wrote:
> > Hello,
> >
> Yo!
> 
> > For debugging purposes, I've added a unique id member to the Value class:
> >
> > global_next_vuid = 0;
> > Value::Value(..){
> >   vuid = ++global_next_vuid;
> > }
> >
> > My hope is that by looking at the vuid of a Value, I can see its vuid,
> > set a conditional breakpoint and re-run the compiler to
> > see who (what pass) constructed that value.
> >
> > Maybe I am not doing it the right way, but the above 'vuid' field doesn't
> > seem
> > to be updated deterministically.
> >
> We'd need a testcase to see what you mean...I'm not entirely sure that
> what you're doing will work, though.
> 
> > I am using a DEBUG built. Is LLVM multithreaded by default?
> >
> No. LLVM isn't multithreaded safe just yet.
> 
> > Is it possible to get a deterministic behavior?
> >
> The code that's generated should be completely deterministic.
> 
> -bw
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_________________________________________________________________
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090519/380e56f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try_calls_basic.2.c
Type: text/x-csrc
Size: 593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090519/380e56f5/attachment.c>