[LLVMdev] Opaque type
gordonhenriksen at mac.com
Mon Jan 14 07:27:32 PST 2008
On 2008-01-14, at 09:30, ac at tml.hut.fi wrote:
> I'm trying to translate part of Java code in LLVM code. I have some
> problems with the "opaque type", I think because I did not
> understand how to use.
> So, the java code is:
> int ai;
> ai = new int;
BTW, if the size of the array is not knowable at compile time, you'll
want to type ai as i32* rather than [n x i32]*. Doing so will avoid
abstract type wrangling.
> I am using LLVM API in this way:
> //I create a pointer of Opaque type, because I don't know yet the
> array size!
> OpaqueType* ot = OpaqueType::get();
> AllocaInst* ptr_addrOP = new AllocaInst(ot, "ai_addr", label_entry);
> //I create pointer of Array type when it is initialized
> ArrayType* art = ArrayType::get(Type::IntTy, 1);
> AllocaInst* ptr_addrAr = new AllocaInst(art, "ai_addr", label_entry);
> //I try to make concrete the abstract pointer
> ((PointerType*)ptr_addrOP -> getType()) ->
> typeBecameConcrete(ptr_addrAr-> getType());
The method you used is somewhat an implementation detail. You want to
use this method to invoke the complete algorithm:
> But "ptr_addrOP" type is still abstract and nothing changed, in the
> SymbolTable there are still both the pointers.
To avoid a dangling pointer, you'll need to use a PATypeHolder (PA for
potentially abstract) to maintain reference to the opaque type across
the call to refineAbstractTypeTo. To understand why, recognize that
the type is not updated in-place, but rather the concrete type is
created, all uses of the opaque type are replaced by the concrete one,
and then the opaque type is deleted. Unless your code participates in
the replacement phase, your local variable will point into freed memory.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev