[LLVMdev] generating instructions with embedded ConstantExprs from within LLVM

Chris Lattner sabre at nondot.org
Thu Jun 17 12:24:00 PDT 2004


On Thu, 17 Jun 2004, Patrick Meredith wrote:

> How is this done?  Everything logical I have tried has failed, here was
> one attempt:

Can you give a few more details about what you are doing?  Are you running
the verifier before writing out bytecode?  Is your code operating as a
pass?  Can you send a dump of the generated LLVM code?

>  Constant *C = (Constant*) ConstantArray::get(inst2string(I));  //fucnction defined elsewhere

One comment about this code: you don't need to have all of these casts.
In particular, above you don't need the (Constant*) cast, and you don't
need the (Value*) casts below.

> //generates a correct Global string
>    GlobalVariable *str = new GlobalVariable(C->getType(), true,
>      GlobalValue::InternalLinkage,
>       C,  mkStrName( strNumber++ ), &M);

You probably don't need mkStrName here.  Just use a constant name like
"debugstr" or whatever.  The symbol table class will autonumber them for
you to keep them unique, and is likely to be more efficient than this
implementation.

>    std::vector<Value*> params;  //params to a CallInst
>    std::vector<Value*> indices;  //indices to gep
>    indices.push_back((Value*) (ConstantInt::get(Type::IntTy, 0)));
>    indices.push_back((Value*) (ConstantInt::get(Type::IntTy, 0)));
>    Constant *gep = ConstantExpr::getGetElementPtr( (Constant*) str, indices);

This looks fine, but you can drop the casts.

>    params.push_back((Value*) gep );
>
>     CallInst *CI = new CallInst(printf, params, std::string(""), I);

You can just pass in "" here instead of std::string("") btw.

>   This resulted in a "no such type plane" assertion.  Currently I am
> doing this as two seperate instructions, which works, but slows down the
> rest of my pass.

I'm really not sure what's going on without more detail.  In particular,
this assertion can happen if you attempt to write an invalid LLVM module
to bytecode.  Make sure that the type of the gep value matches the first
argument to printf.  If you run the verifier it should catch problems like
this (the verifier should automatically be run if you're a pass running
from opt), If the verifier doesn't catch the problem, then it's a bug in
the verifier and please let me know!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/




More information about the llvm-dev mailing list