[LLVMdev] ML types in LLVM

[John McCall]

On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote:
> Currently I just represent %c as i8*. I assume that this can have
> consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
> like that. Is there any way to better represent the type %c to LLVM?

I assume this is for tagged sums.

Logically, what you want is a distinct LLVM type for every ML union type
and each of its constructors.  Unfortunately, LLVM does structural
uniquing of types, so that won't work.  What you can do is abuse address
spaces, giving every distinct type its own address space and casting
back and forth between address spaces as necessary.

> Is there any way to express that a pointer is actually a pointer to an
> interior element of a type? Something like %opt_33_in_heap =
> %opt_33_with_header:1 ?

Something like an ungetelementptr?  No, sorry.  That would be a
pretty nice extension, though obviously unsound, of course.

> Currently when I want to read the header of an %opt_33, I cast it to a
> i32* and then use getelementptr -1. Is there a better way?

I think it depends on (1) exactly how your runtime environment lays out
the header and (2) whether you're trying to create portable IR (as  
opposed
to creating IR portably).

Personally, I would create a struct type (hereafter "HeaderType") for  
the
entire GC header;  when you want to access a header field, just cast the
base pointer to i8*, subtract the allocation size of HeaderType, cast  
the
result to HeaderType*, and getelementptr from there.  That doesn't
make portable IR, of course, but in the absence of an ungetelementptr
instruction, I'm not sure how you could do that better.

You can portably get the allocation size of a type using
TargetData::getTypeSizeInBits().

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090613/eaa8566d/attachment.html>