[llvm-dev] Force casting a Value*

[Dipanjan Das via llvm-dev]

On 11 June 2017 at 18:22, don hinton <hintonda at gmail.com> wrote:

> Sure, you can call store_inst->getOperand(0)->getType(), and call
> different functions based on the type, e.g., foo_8, foo_16, foo_32, etc...
>
> Here's an example of how you could do it: https://github.com/
> donhinton/CVRFI/blob/master/lib/pass/Node.cpp#L224
>
>
You are dispatching call to different functions depending on if it's a
LoadInst/StoreInst/CallInst. I am using a similar structure in my project,
too. However, irrespective of the Type of the argument (i.e.
i32/i32*/i32**), I just need its value (store_inst->getValueOperand() which
is the same as store_inst->getOperand(0)). I want to ignore the type in
this case. I feel there should be some unified means to deal all the cases
in a single function. If I treat all the point values as uint64_t, that
should solve the problem. But, I am scratching my head since last one day
to figure out how to convince LLVM ignore the pointer type and just pass on
its value as an unsigned, 64 bit integer.


>
> On Sun, Jun 11, 2017 at 6:05 PM, Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On 11 June 2017 at 14:04, don hinton <hintonda at gmail.com> wrote:
>>
>>> Assuming you know it's a 64 bit value, and the function you are calling
>>> takes a uint64_t, try this:
>>>
>>
>> The values from the test program are of type: i32/i32*/i32**. Can't I
>> interpret these as uint64_t some way?
>>
>>
>>>
>>> Value* args[] = {store_inst->getOperand(0)};
>>>
>>>
>>> On Sun, Jun 11, 2017 at 1:16 PM, Dipanjan Das via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>>
>>>>
>>>> On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com>
>>>> wrote:
>>>>
>>>>> On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev
>>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>> > I can't pass var_value to a function accepting uint64_t. LLVM
>>>>> complains
>>>>> > about broken function call.
>>>>>
>>>>> Well, yes. var_value has type "ConstantInt *", not uint64_t. Assuming
>>>>> the value being stored actually is a constant known at compile-time
>>>>> you should be able to use cast<ConstantInt *>(vo)->getZExtValue() to
>>>>> retrieve a uint64_t value (careful of i128s!).
>>>>>
>>>>> If that cast fails then you're not dealing with a constant store. This
>>>>> is either a nuisance (if you were expecting the possibility and can
>>>>> deal with it) or a huge misunderstanding over compile-time vs runtime
>>>>> values.
>>>>>
>>>>
>>>> I think it's a misunderstanding in may part. Let me explain my
>>>> intention first. I want to retrieve the value (if isPointerTy() returns
>>>> true) to be stored by a store instruction at run-time and pass on that
>>>> value as either an unsigned int (64) or a pointer (char*) to an external
>>>> function. The call to that function is inserted using
>>>> IRBuilder.CreateCall().
>>>>
>>>> Consider the code snippet below.
>>>>
>>>> ==================================================
>>>>
>>>> if (StoreInst *store_inst = dyn_cast<StoreInst>(&I)) {
>>>>                     Value* vo = store_inst->getValueOperand();
>>>>                      uint64 var_value = /* cast vo to unsigned int 64
>>>> bit */
>>>>
>>>>                    // Pass on this value to external function
>>>>                     IRBuilder<> builder(&I);
>>>>                     builder.SetInsertPoint(&B,
>>>> ++builder.GetInsertPoint());
>>>>                     Constant *func = F.getParent()->getOrInsertFunc
>>>> tion("instrument_store",
>>>>
>>>> Type::getVoidTy(Ctx), Type::getInt8PtrTy(Ctx), NULL);
>>>>                     Value* args[] = {var_value};
>>>>                     builder.CreateCall(func, args);
>>>>  }
>>>>
>>>> ==================================================
>>>>
>>>> To reiterate, I want to wrap up the run-time value (var_value) as a
>>>> Value* and call the method (instrument_store) with that value as an
>>>> argument.
>>>>
>>>>
>>>>
>>>>> If it's a nuisance, you can use "dyn_cast" instead of "cast". That'll
>>>>> return nullptr if the store wasn't a constant instead of crashing; you
>>>>> can decide what to do at that point.
>>>>>
>>>>> Cheers.
>>>>>
>>>>> Tim.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Thanks & Regards,
>>>> Dipanjan
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Thanks & Regards,
>> Dipanjan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>


-- 

Thanks & Regards,
Dipanjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170611/533678c4/attachment.html>