llvm dev - Jan 2008 - [LLVMdev] C embedded extensions and LLVM

>>> Please add a generous block comment to
>>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum  
>>> explaining
>>> what the difference is though. :)
>>
>
> Should have said:
>
>> Should I take the same approach to the encoding of pointer types in  
>> the types table?
PointerTypes are a bit easier.  The code to write them looks like this:

     case Type::PointerTyID:
       // POINTER: [pointee type]
       Code = bitc::TYPE_CODE_POINTER;
       TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- 
 >getElementType()));


The code to read them look like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       ResultTy = PointerType::get(getTypeByID(Record[0], true));
       break;

The interesting point here is that PointerType currently has one field  
(that it push_back's onto TypeVals).  The reader requires this field  
to be present, but ignores any additional fields.  You should just be  
able to add another typeVals.push_back() to the writer, and the  
readers will be transparently compatible with it.  Just make the new  
reader do something like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       unsigned AddrSpace = Record.size() >= 2 ? Record[1] : 0;
       ...

-Chris

Christopher,
It has been a while since we last talked about C embedded extensions in
LLVM, I was moving back and froth from project to project and didn't get
a chance to follow up. I was wondering if you have made any changes to
LLVM IR and if so what has been added. And how can I contribute?

Thanks
A.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Chris Lattner
Sent: Sunday, November 25, 2007 2:08 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] C embedded extensions and LLVM
>>> Please add a generous block comment to
>>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum  
>>> explaining
>>> what the difference is though. :)
>>
>
> Should have said:
>
>> Should I take the same approach to the encoding of pointer types in  
>> the types table?
PointerTypes are a bit easier.  The code to write them looks like this:

     case Type::PointerTyID:
       // POINTER: [pointee type]
       Code = bitc::TYPE_CODE_POINTER;
       TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- 
 >getElementType()));


The code to read them look like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       ResultTy = PointerType::get(getTypeByID(Record[0], true));
       break;

The interesting point here is that PointerType currently has one field  
(that it push_back's onto TypeVals).  The reader requires this field  
to be present, but ignores any additional fields.  You should just be  
able to add another typeVals.push_back() to the writer, and the  
readers will be transparently compatible with it.  Just make the new  
reader do something like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       unsigned AddrSpace = Record.size() >= 2 ? Record[1] : 0;
       ...

-Chris
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jan 29, 2008, at 9:56 AM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com
 > wrote:
> Christopher,
> It has been a while since we last talked about C embedded extensions  
> in
> LLVM, I was moving back and froth from project to project and didn't  
> get
> a chance to follow up. I was wondering if you have made any changes to
> LLVM IR and if so what has been added. And how can I contribute?
My understanding is that Christopher's patches have all landed in  
llvm, so the IR is capable of capturing and propagating the address  
space information.  However, we have no front-end that correctly  
generates this.  My understanding is that Christopher has patches in  
progress to add this to clang, but I'm not sure what the state of  
these is.  It would be great to get have help getting this into clang.

-Chris