[LLVMdev] Need Help With Verifier

Reid Spencer reid at x10sys.com
Fri Nov 21 10:59:02 PST 2003


While it is great that LLVM has an IR Verifier, its a little troublesome
to use because it separates the point of detection from the source of
the problem. That is, the verifier gets run on a module or function
after its been built. By that point, the compiler's state has moved past
the point at which the error was placed into the module or function.
Trying to track down the source of the problem from the scant
information produced by the verifier is turning out to be tedious for me
(i.e. spent several hours at it, no results).

Now, here's the specific problem. When the verifier runs, I get:

Stored value is not of right type for indices!
void <badref>
type[1024 x int] [1024 x int]

So, I've tracked this down to being one of three StoreInst instructions.
In particular, its one of the two StoreInst instructions I generate that
write into a global array of int (Stacker's global stack).

Here's what I don't understand:

The first operand of the StoreInst is being reported as "void <badref>".
First, I don't really know what this means but I assume its just an
invalid references of some sort.  The only thing I store into the array
is an "IntTy". I use a GEP instruction to index into the stack and then
generate the store instruction like this:

> ConstantInt* val = ConstantInt::get( Type::IntTy, value );
> bb->getInstList().push_back( new StoreInst( val, gep ) );

How could this "ConstantInt" value be reported as "void <badref>" ?

The next thing that troubles me is that the verifier output for the
second operand indicates a two dimensional array. This just isn't right,
its one dimensional.  Here's how I create the global array for the stack
(used to form the "gep" in the above code):

> ArrayType* stack_type = ArrayType::get( Type::IntTy, stack_size );
>                                                                                                                                                              
> TheStack = new GlobalVariable(
>      /*type=*/ stack_type,
>      /*isConstant=*/ false,
>      /*Linkage=*/ GlobalValue::AppendingLinkage,
>      /*initializer=*/0,
>      /*name=*/ "_stack_",
>      /*parent=*/ TheModule
> );

Shouldn't that create just a single dimensioned array? Note that
"stack_size" is an integer with the value 1024. 


Finally, I have some confusion about how SSA works with LLVM. If I
understand the documentation correctly, there is no distinction between
an instruction that creates a value and the value itself. This
understanding comes from the Programmer's Manual:

        "One important aspect of LLVM is that there is no distinction
        between an SSA variable and the operation that produces it.
        Because of this, any reference to the value produced by an
        instruction (or the value available as an incoming argument, for
        example) is represented as a direct pointer to the class that
        represents this value. Although this may take some getting used
        to, it simplifies the representation and makes it easier to
        manipulate."

So, for example, if I want to add two numbers stored in memory, I add
the two load instructions used to fetch the values. Right? Please say
yes or I have to change my whole conception of how this works! :)

Okay, so one of the built-in operations in Stacker is to push an integer
onto the stack. This is done by just mentioning the integer value as in
Forth. For example,

: PushOne 1 ;

is Stackerese for defining a function that pushes the value 1 onto the
stack. To implement "PushOne", I have to conceptually do this:

     1. Load the integer stack index (LoadInst)
     2. Increment the index (Add BinaryOperator)
     3. Get the address of the stack element at that index (GEP)
     4. Store the value 1 at that address (StoreInst).

Item 4 represents the StoreInst that the verifier is complaining about.
So, below is how I did the above sequence. I thought it was pretty
straight forward, but I've obviously done something wrong!

In the following, note that "TheIndex" is a GlobalVariable of type
"LongTy", "TheStack" is the [1024xint] array that I mentioned above. The
BasicBlock variable bb is passed in from a higher level in the
compiler's call sequence. 

void
StackerCompiler::incr_stack_index( BasicBlock* bb )
{
    ConstantInt* ival = ConstantInt::get(Type::LongTy, 1);
    
    LoadInst* loadop = new LoadInst( TheIndex );
    bb->getInstList().push_back( loadop );

    BinaryOperator* addop = BinaryOperator::create( 
        Instruction::Add, loadop, ival);
    bb->getInstList().push_back( addop );

    StoreInst* storeop = new StoreInst( addop,
        TheIndex );
    bb->getInstList().push_back( storeop );
}
                                                                                                                                                             
GetElementPtrInst*
StackerCompiler::get_stack_pointer( BasicBlock* bb )
{
    LoadInst* loadop = new LoadInst( TheIndex );
    bb->getInstList().push_back( loadop );
 
    std::vector<Value*> indexVec;       // Index vector
    indexVec.push_back(loadop);         // Insert single index

    GetElementPtrInst* gep = new GetElementPtrInst( 
        TheStack, indexVec );
    bb->getInstList().push_back( gep );         // Put GEP in Block

    return gep;
}

void
StackerCompiler::push_integer(BasicBlock* bb, int32_t value )
{
    incr_stack_index(bb);

    GetElementPtrInst* gep = get_stack_pointer( bb );

    ConstantInt* val = ConstantInt::get( Type::IntTy, value );

    bb->getInstList().push_back( new StoreInst( val, gep ) );
}
                                                                                                                                                             Thanks in advance for any light you can shed on this. I'm stumped.

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031121/a15d7bc3/attachment.sig>


More information about the llvm-dev mailing list