How to know the sub-class of a Value class?

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:

Try value->dump() assuming you’re using a debug build.

http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates

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.

http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-
templates

I understand isa and dyn-cast let you test the type of an object at
run-time by leveraging LLVM's custom implementation of RTTI. However, it
doesn't make much sense to test out for all possible sub-classes to get to
know what it actually is. If I just want to know sub-class a Value* is,
what's the way out (other than testing with isa<>())?

Does this pattern (or some variant of it) solve your problem:
https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/BasicAliasAnalysis.cpp#L232

?

-- Sanjoy

I’m certainly no expert, but how you use that Value* would depend on what you want to do with it.

From the documentation, it looks like Value->getValueID() is how the RTTI implementation determines the subclass.
So you could switch over the values returned (defined in llvm/IR/Value.def).

Or dyn_cast to each of the types you need to deal with. Or use some other helper functions that strip noops like bitcasts for you.

Does this pattern (or some variant of it) solve your problem:

https://github.com/llvm-mirror/llvm/blob/master/lib/
Analysis/BasicAliasAnalysis.cpp#L232

It switches over BinaryOperator->getOpcode(). I don't think it addresses my
query.

In my <llvm-root>/include/llvm/IR/Value.def, there's no mapping between the
numeric ID (as returned by getValueID()) and corresponding sub-class.

Thanks & Regards,
Dipanjan

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 , e.g., i64 0 or double 0.0. The ConstantAggregateZero class shows up as zeroinitializer, and ConstantExprs show up as something like trunc ( to ). 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”; }

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...

Sure you could do that. eg;

https://github.com/llvm-mirror/llvm/blob/e3e43d9d574cf0a829e9a58525372ba0868a3292/lib/IR/Globals.cpp#L85

Or use the enum names;
https://github.com/llvm-mirror/llvm/blob/e3e43d9d574cf0a829e9a58525372ba0868a3292/lib/Transforms/Utils/FunctionComparator.cpp#L248

Like I said, how you determine what you’re looking at might change based on what you want to do with each subclass of Value, which still hasn’t been clarified.

You get better answers if you ask more specific questions and provided more context. And lately it seems like you’ve been asking a lot of questions.

Why do you need to know the specific type of a Value * ?
Or, implicit in your question, what types of stored values are you looking for?

Do you want to look through bitcasts to discover the source Value?

Is this an attempt to get a different answer to your “[llvm-dev] Force casting a Value*” question?