Sorry, I'm a bit confused by your reply. I think part of my problem is
I can only think of this in terms of Passes.
For instance, my pass looks for assignments and tries to use the same
pointer operand, before the assignment it finds. Like this:
new ICmpInst(*block, CmpInst::ICMP_NE, shadow,
store->getPointerOperand(), "Shadow check");
So I'm not sure how alloca could help me, seems like it wouldn't be a
valid Value * for me to pass in at that point. Am I missing something?
Thank you
On Mon, Sep 19, 2011 at 2:02 PM, John Criswell <criswell at illinois.edu>
wrote:> On 9/19/11 12:53 PM, ret val wrote:
>>
>> Is there a easy way to copy a Value object, so it can be used in
>> multiple instructions without a dominance issue?
>
> A value object can be used multiple times with no problem.
>
> The dominance problem stems from the fact that the program must be in SSA
> form. When the program uses a value, it must have been defined dynamically
> for all possible executions of the program. This is why the definition of
a
> value must dominate all of its uses.
>
> If you're instrumenting code and having trouble meeting the dominance
> requirement, what you should do is add the "variable" as an
alloca'ed stack
> variable that is read/written by loads/stores instead of as an SSA value
> that is defined only once.
>
> For example, instead of adding code that does this:
>
> %y = add %x, 5
> ...
> %z = sub %y, 2
>
> ... you add this:
>
> entry_block:
> %yp = alloca <type of y>
> ...
> %y1 = add %x, 5
> store %y1, %yp
> ...
> %y2 = load %yp
> %z = sub %y2, 2
>
> The second version of the code allows the "variable" stored into
the
> alloca'ed memory to never have been initialized or to be written
multiple
> times. You are freed from trying to keep %y in valid SSA form at all
times.
>
> After your pass is run, you can run the -mem2reg pass. This pass will
> convert your instrumented code into SSA form (i.e., it will change the
> second version of the code into the first version of the code).
>
> -- John T.
>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
On 9/19/11 2:48 PM, ret val wrote:> Sorry, I'm a bit confused by your reply. I think part of my problem is > I can only think of this in terms of Passes. > > For instance, my pass looks for assignments and tries to use the same > pointer operand, before the assignment it finds. Like this: > new ICmpInst(*block, CmpInst::ICMP_NE, shadow, > store->getPointerOperand(), "Shadow check");Can you clarify what you mean by "an assignment?" Do you mean an LLVM store instruction, or do you mean an SSA assignment of an LLVM virtual register?> > So I'm not sure how alloca could help me, seems like it wouldn't be a > valid Value * for me to pass in at that point. Am I missing something?Perhaps this would be easier if I knew what your pass is trying to do. Can you explain what you are trying to do? -- John T.> > Thank you > > On Mon, Sep 19, 2011 at 2:02 PM, John Criswell<criswell at illinois.edu> wrote: >> On 9/19/11 12:53 PM, ret val wrote: >>> Is there a easy way to copy a Value object, so it can be used in >>> multiple instructions without a dominance issue? >> A value object can be used multiple times with no problem. >> >> The dominance problem stems from the fact that the program must be in SSA >> form. When the program uses a value, it must have been defined dynamically >> for all possible executions of the program. This is why the definition of a >> value must dominate all of its uses. >> >> If you're instrumenting code and having trouble meeting the dominance >> requirement, what you should do is add the "variable" as an alloca'ed stack >> variable that is read/written by loads/stores instead of as an SSA value >> that is defined only once. >> >> For example, instead of adding code that does this: >> >> %y = add %x, 5 >> ... >> %z = sub %y, 2 >> >> ... you add this: >> >> entry_block: >> %yp = alloca<type of y> >> ... >> %y1 = add %x, 5 >> store %y1, %yp >> ... >> %y2 = load %yp >> %z = sub %y2, 2 >> >> The second version of the code allows the "variable" stored into the >> alloca'ed memory to never have been initialized or to be written multiple >> times. You are freed from trying to keep %y in valid SSA form at all times. >> >> After your pass is run, you can run the -mem2reg pass. This pass will >> convert your instrumented code into SSA form (i.e., it will change the >> second version of the code into the first version of the code). >> >> -- John T. >> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>
Sorry, by assignment I do mean a StoreInst. My pass looks for "interesting" StoreInsts that act on certain variables. For each of these variables I already created a "dummy" variable that for right now should match the original. So if variable a is interesting, it means I already created a new variable a', and I caught it in a StoreInst instruction. From here I want to insert instructions that will first check to make sure they match(a = a;), and then apply the StoreInst to a'. Then the code resumes. Basically they should mirror each other and Id like to make sure they are still mirror before changes. So thats how I ran into this problem, I would like to "borrow" the Value arg. Thanks again, hope that makes some sense On Mon, Sep 19, 2011 at 4:09 PM, John Criswell <criswell at illinois.edu> wrote:> On 9/19/11 2:48 PM, ret val wrote: >> >> Sorry, I'm a bit confused by your reply. I think part of my problem is >> I can only think of this in terms of Passes. >> >> For instance, my pass looks for assignments and tries to use the same >> pointer operand, before the assignment it finds. Like this: >> new ICmpInst(*block, CmpInst::ICMP_NE, shadow, >> store->getPointerOperand(), "Shadow check"); > > Can you clarify what you mean by "an assignment?" Do you mean an LLVM store > instruction, or do you mean an SSA assignment of an LLVM virtual register? >> >> So I'm not sure how alloca could help me, seems like it wouldn't be a >> valid Value * for me to pass in at that point. Am I missing something? > > Perhaps this would be easier if I knew what your pass is trying to do. Can > you explain what you are trying to do? > > -- John T. > >> >> Thank you >> >> On Mon, Sep 19, 2011 at 2:02 PM, John Criswell<criswell at illinois.edu> >> wrote: >>> >>> On 9/19/11 12:53 PM, ret val wrote: >>>> >>>> Is there a easy way to copy a Value object, so it can be used in >>>> multiple instructions without a dominance issue? >>> >>> A value object can be used multiple times with no problem. >>> >>> The dominance problem stems from the fact that the program must be in SSA >>> form. When the program uses a value, it must have been defined >>> dynamically >>> for all possible executions of the program. This is why the definition >>> of a >>> value must dominate all of its uses. >>> >>> If you're instrumenting code and having trouble meeting the dominance >>> requirement, what you should do is add the "variable" as an alloca'ed >>> stack >>> variable that is read/written by loads/stores instead of as an SSA value >>> that is defined only once. >>> >>> For example, instead of adding code that does this: >>> >>> %y = add %x, 5 >>> ... >>> %z = sub %y, 2 >>> >>> ... you add this: >>> >>> entry_block: >>> %yp = alloca<type of y> >>> ... >>> %y1 = add %x, 5 >>> store %y1, %yp >>> ... >>> %y2 = load %yp >>> %z = sub %y2, 2 >>> >>> The second version of the code allows the "variable" stored into the >>> alloca'ed memory to never have been initialized or to be written multiple >>> times. You are freed from trying to keep %y in valid SSA form at all >>> times. >>> >>> After your pass is run, you can run the -mem2reg pass. This pass will >>> convert your instrumented code into SSA form (i.e., it will change the >>> second version of the code into the first version of the code). >>> >>> -- John T. >>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > >