RE: [LLVMdev] Port to Solaris' Sun Studio 8

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

-Chris