[cfe-commits] r125562 - in /cfe/trunk/lib/CodeGen: CGBlocks.cpp CGDecl.cpp CGExpr.cpp CGExprScalar.cpp CodeGenFunction.cpp CodeGenFunction.h CodeGenModule.cpp CodeGenModule.h

[John McCall]

On Feb 15, 2011, at 7:54 AM, Ken Dyck wrote:

> On Tue, Feb 15, 2011 at 4:22 AM, John McCall <rjmccall at apple.com> wrote:
>> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.h?rev=125562&r1=125561&r2=125562&view=diff
>> ==============================================================================
>> --- cfe/trunk/lib/CodeGen/CodeGenModule.h (original)
>> +++ cfe/trunk/lib/CodeGen/CodeGenModule.h Tue Feb 15 03:22:45 2011
>> @@ -94,10 +94,39 @@
>>       return priority == RHS.priority && lex_order < RHS.lex_order;
>>     }
>>   };
>> +
>> +  struct CodeGenTypeCache {
>> +    /// i8, i32, and i64
>> +    const llvm::IntegerType *Int8Ty, *Int32Ty, *Int64Ty;
>> +
>> +    /// int
>> +    const llvm::IntegerType *IntTy;
>> +
>> +    /// intptr_t and size_t, which we assume are the same
>> +    union {
>> +      const llvm::IntegerType *IntPtrTy;
>> +      const llvm::IntegerType *SizeTy;
>> +    };
>> +
>> +    /// void* in address space 0
>> +    union {
>> +      const llvm::PointerType *VoidPtrTy;
>> +      const llvm::PointerType *Int8PtrTy;
>> +    };
>> +
>> +    /// void** in address space 0
>> +    union {
>> +      const llvm::PointerType *VoidPtrPtrTy;
>> +      const llvm::PointerType *Int8PtrPtrTy;
>> +    };
>> +
>> +    /// The width of an address-zero pointer.
>> +    unsigned char PointerWidthInBits;
>> +  };
> 
> Nice. Collecting these type definitions into a single location looks
> like it will be a big help when it comes to generalizing the code
> generator for non-8-bit chars. Do you think it will be
> possible/advisable to eventually replace these Int8 types with ones
> that are tied to the size of the C-level char type?

That's my thinking.  It's possible that LLVM would want to separate some
things as always being i8* vs. char*, in which case we'd need to audit
all the uses in Clang, but using a consistent place that builds that type
will be convenient for that refactor.

John.