llvm dev - Jun 2017 - How to know the sub-class of a Value class?

On 11 June 2017 at 23:03, Craig Topper <craig.topper at gmail.com> wrote:
> Try value->dump() assuming you're using a debug build.
>
>
The information displayed is non-uniform. There are two different cases
based on my sample program:

         (1) dump() shows the Type and *some* value which I don't
understand what it is
         (2) dump() shows the instruction that creates the Value*

But, it doesn't display the concrete sub-class.


> ~Craig
>
> On Sun, Jun 11, 2017 at 10:54 PM, Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> As a concrete question, I understand 'Value' class is the
parent of many
>> concrete sub-classes. Let's say I retrieve a Value* value >>
store_inst->getValueOperand(). Unless I know what the sub-type is, how can
>> I further use this object? I tried something like this:
>>
>> ================================================>>
>>          Value* value = store_inst->getValueOperand()
>>          errs() << value->getValueID; // Which ID corresponds
to which
>> sub-class?
>>          errs() << value->getValueName(); // Prints numeric
memory
>> addresses
>>          errs() << *value->getValueName(); // Doesn't
compile
>>
>> ================================================>>
>> I have mentioned the issues in each of the cases above. I am not sure
if
>> the approach is correct or not. Please help me out.
>>
>> --
>>
>> 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/7adf551d/attachment.html>

On 6/12/17 1:09 AM, Dipanjan Das via llvm-dev wrote:
>
>
> On 11 June 2017 at 23:03, Craig Topper <craig.topper at gmail.com 
> <mailto:craig.topper at gmail.com>> wrote:
>
>     Try value->dump() assuming you're using a debug build.
>
>
> The information displayed is non-uniform. There are two different 
> cases based on my sample program:
>
>          (1) dump() shows the Type and *some* value which I don't 
> understand what it is
>          (2) dump() shows the instruction that creates the Value*
>
> But, it doesn't display the concrete sub-class.
The LLVM class names are largely one-to-one with the instructions 
defined in the LLVM Language Reference. The main exception is the class 
of operators that get bundled into the BinaryOperator class (e.g., add, 
or, xor, fadd, etc.), and BinaryOperator is one of those classes that 
Doxygen completely chokes on since it's so macro-heavy. Browsing the 
subclass list of llvm::Instruction on Doxygen for something that looks 
like the name of the instruction in question.

The other main set of values are the constants. In the dump output, 
constant scalars (such as ConstantFP, ConstantInt, ConstantPointerNull) 
show up as <type> <val>, e.g., i64 0 or double 0.0. The 
ConstantAggregateZero class shows up as zeroinitializer, and 
ConstantExprs show up as something like trunc (<expr> to <ty>).
Again,
you can read the language manual to see examples, it's usually pretty 
clear what type something is.

If you're dead set on actually printing the name of the class of a 
Value, there's no canned method to do that. Something like this code 
would work (untested):
const char *kind_name = nullptr;
switch(val->getValueID()) {
#define HANDLE_VALUE(name) case Value::name##Val: kind_name = #name; break;
default: kind_name = "well this was unexpected";
}

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170612/c04a5eaf/attachment.html>

On 6/12/17 1:34 AM, Joshua Cranmer 🐧 wrote:
> If you're dead set on actually printing the name of the class of a 
> Value, there's no canned method to do that. Something like this code 
> would work (untested):
> const char *kind_name = nullptr;
> switch(val->getValueID()) {
> #define HANDLE_VALUE(name) case Value::name##Val: kind_name = #name; 
> break;
> default: kind_name = "well this was unexpected";
> }
Arggh, I'm an idiot. The correct code should be:
const char *kind_name = nullptr;
switch(val->getValueID()) {
#define HANDLE_VALUE(name) case Value::name##Val: kind_name = #name; break;
#include "llvm/IR/Value.def"
#undef HANDLE_VALUE
default: kind_name = "well this was unexpected";
}

The #include is kinda the most important part in that statement...

-- 
Joshua Cranmer
Thunderbird module owner
DXR coauthor