Forcing order of execution

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

Forcing order of execution

Sarah Thompson-2
Hi all,

I'm currently writing a pass that inserts memory tracing calls before
and after store instructions. I need to make sure that these calls, and
the instruction itself, are executed strictly in order, such that no
later stage optimisations reorder the operations. Do I need to do
anything special to make this happen, or will simply having the write
address referenced by both calls and the store be sufficient to prevent
weirdness? Do I need to split the basic block? Is there an easier way to
do it (e.g. an explicit-ordering intrinsic or some such?) I am
bitcasting the pointer from its original type (whatever that may be) to
a sbyte* for the calls (but, for obvious reasons, not the store). My
assumption is that using the pointer in all three cases should result in
strict ordering because program semantics might be affected otherwise.
The tracing functions are external and never inlined, by the way  (they
actually exist outside the JIT environment).

Thanks,
Sarah

PS: Forgive me for asking something that can be verified through
just-trying-it-and-seeing, but this ordering is extremely critical, so I
thought it best to ask rather than guess.

_______________________________________________
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: Forcing order of execution

Chris Lattner
On Thu, 2 Aug 2007, Sarah Thompson wrote:
> I'm currently writing a pass that inserts memory tracing calls before
> and after store instructions. I need to make sure that these calls, and
> the instruction itself, are executed strictly in order, such that no
> later stage optimisations reorder the operations. Do I need to do
> anything special to make this happen, or will simply having the write
> address referenced by both calls and the store be sufficient to prevent
> weirdness?

This should work just fine.  If you pass the address to the call, the
optimizer will assume the called function reads or writes the pointer,
thus it can't reorder it w.r.t. the stores or other calls.

-Chris

> Do I need to split the basic block? Is there an easier way to
> do it (e.g. an explicit-ordering intrinsic or some such?) I am
> bitcasting the pointer from its original type (whatever that may be) to
> a sbyte* for the calls (but, for obvious reasons, not the store). My
> assumption is that using the pointer in all three cases should result in
> strict ordering because program semantics might be affected otherwise.
> The tracing functions are external and never inlined, by the way  (they
> actually exist outside the JIT environment).
>
> Thanks,
> Sarah
>
> PS: Forgive me for asking something that can be verified through
> just-trying-it-and-seeing, but this ordering is extremely critical, so I
> thought it best to ask rather than guess.
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

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