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>