search for: type_code_point

...> > > 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");...

On Nov 24, 2007, at 7:47 PM, Christopher Lamb wrote: > > On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > >> On Wed, 21 Nov 2007, Christopher Lamb wrote: >>>> Unlike alignment and volatility, I think that the address space >>>> qualifier >>>> should be represented explicitly in the type system. The >>>> reason for this

...> > > 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");...

On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > On Wed, 21 Nov 2007, Christopher Lamb wrote: >>> Unlike alignment and volatility, I think that the address space >>> qualifier >>> should be represented explicitly in the type system. The reason >>> for this > >> I've come across a hitch. Store instructions do not reference the