Well, line 364 wasn’t actually what was holding me up, so it’s a bad example, but the problem’s still relevant. Using cast<…>(iter), dyn_cast<…>(iter), or isa<…>(iter) results in the error messages mentioned below.
Michael Smith wrote:
Well, line 364 wasn't actually what was holding me up, so it's a bad
example, but the problem's still relevant. Using cast<...>(iter),
dyn_cast<...>(iter), or isa<...>(iter) results in the error messages
mentioned below.
....
When compiling LoadValueNumbering.cpp, I get the following errors:
"~/bin/../src/include/llvm/Support/Casting.h", line 51: Error: Could not
find a match for llvm::AllocationInst::classof(const
llvm::ilist_iterator<llvm::Instruction>*)."~/bin/../src/include/llvm/Support/Casting.h", line 68: Where: While
instantiating "llvm::isa_impl<llvm::AllocationInst,
llvm::ilist_iterator<llvm::Instruction>>(const
llvm::ilist_iterator<llvm::Instruction>&)"."~/bin/../src/include/llvm/Support/Casting.h", line 68: Where:
Instantiated from non-template code.This seems to be linked with line 364 in LoadValueNumbering.cpp,
The error above suggests that "isa<AllocationInst>(whatever)" was invoked,
and in current CVS, the only use of AllocationInst in
LoadValueNumbering.cpp is on line 305:
if (isa<AllocationInst>(I))
RetVals.push_back(UndefValue::get(LI->getType()));
I think changing this to
if (isa<AllocationInst>(*I))
RetVals.push_back(UndefValue::get(LI->getType()));
should work, and be more robust anyway then relying on implicit
interator->value conversion anyway. If you'd want to debug this, try
compiling the following program:
#include "llvm/Analysis/LoadValueNumbering.h"
#include "llvm/Support/Casting.h"
#include "llvm/Support/BasicBlock.h"
using namespace llvm;
template<class T>
void test(const T& val)
{
simplify_type<T>::getSimplifiedValue(val).no_such_method();
}
void foo()
{
BasicBlock::iterator I;
test(I);
}
With the following command:
CC -I <path-to-llvm-includes-directory> -D__STDC_LIMIT_MACROS=1
file.cpp
You should get one compile error on attempt to call 'no_such_method' on
results of 'getSimplifiedValue', and the error message should name the type
of the object you call method on. With gcc/Linux, that type is
'llvm::Instruction*'. If you see anything else, this means 'simplify_type'
is broken, and most probable reason is that the compiler has broken partial
template specialisation.
Some workarounds may be possible, but adding '*' everywhere dynamic casting
is used might be easier solution.
- Volodya
The error above suggests that "isa<AllocationInst>(whatever)" was invoked,
and in current CVS, the only use of AllocationInst in
LoadValueNumbering.cpp is on line 305:if (isa<AllocationInst>(I))
RetVals.push_back(UndefValue::get(LI->getType()));I think changing this to
if (isa<AllocationInst>(*I))
RetVals.push_back(UndefValue::get(LI->getType()));should work,
Yes, quite true.
and be more robust anyway then relying on implicit
interator->value conversion anyway.
I don't think this is a robustness issue: the casting machinery has explicit knowledge that it should autodereference these iterators. Somehow this is getting picked up on GCC but not on Sun CC. I think that it's just a missing specialization (which I posted).
You should get one compile error on attempt to call 'no_such_method' on
results of 'getSimplifiedValue', and the error message should name the type
of the object you call method on. With gcc/Linux, that type is
'llvm::Instruction*'. If you see anything else, this means 'simplify_type'
is broken, and most probable reason is that the compiler has broken partial
template specialisation.
Agreed 100%.
Some workarounds may be possible, but adding '*' everywhere dynamic casting
is used might be easier solution.
If it comes to that, we can do that. 
-Chris