[LLVMdev] Opaque type

[Gordon Henriksen]

Hi,

On 2008-01-14, at 09:30, ac at tml.hut.fi wrote:

> Hello,
> 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[1];

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:

http://llvm.org/docs/ProgrammersManual.html#refineAbstractTypeTo

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

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080114/0a39d347/attachment.html>