search for: getabitypesize

...needs to be at least as big as (3). (5) needs to be at least as big as (4). Another example is 80-bit floating point types. Here (1), (2) and (3) are presumably 80 bits. On my machine (5) is 96 bits. I'm not sure what (4) is, presumably 80 or 96. Which (if any) of these should getTypeSize, getABITypeSize, getTypeSizeInBits and getABITypeSizeInBits correspond to? It seems clear that getTypeSizeInBits corresponds to (1) and (2), as shown by it returning 36 for i36. This is like gcc's TYPE_PRECISION, and is a useful concept - but I think the name should be changed, since right now it implicitly...

...it's part of a larger object (i.e. 40?). > > Another example is 80-bit floating point types. Here (1), (2) > and (3) are presumably 80 bits. On my machine (5) is 96 bits. > I'm not sure what (4) is, presumably 80 or 96. > > Which (if any) of these should getTypeSize, getABITypeSize, > getTypeSizeInBits > and getABITypeSizeInBits correspond to? TypeSize == "real size", ABITypeSize == "abi size". You will need another pair for the storage size? > > It seems clear that getTypeSizeInBits corresponds to (1) and (2), as > shown by it returni...

...doesn't seem worth the trouble. > Should (4) be the same as (5) since alloca / malloc are allocating an > array of the specific type? Yes, I think so. Currently alloca allocates a multiple of getTypeSize (see visitAlloca in SelectionDAGISel). This seems to be a bug - it needs to use getABITypeSize. This also means that all the (many) places that use getTypeSize as the amount of memory allocated by an alloca need to be changed... > > In general (1) and (2) will be the same. (4) needs to be at least > > as big as (3). (5) needs to be at least as big as (4). > > Do you re...

...caHolderHandleD1Ev+0x37)[0x84bcbab] lli(_ZN4llvm16ExecutionContextD1Ev+0x14)[0x84bd780] lli(_ZN9__gnu_cxx13new_allocatorIN4llvm16ExecutionContextEE7destroyEPS2_+0x11)[0x84bd7af] ... ... I checked the llvm svn log, this is due to the patch from " svn diff -r43619:43620" The replacement of getABITypeSize with getTypeSize caused it. This seems an alignment unmatch issue. As for type i75, the getABITypeSize/getABITypeAlignment will return 10 while in APInt, it actually allocated two-64bit-array (128bit totally) hence the malloc/free crashed. Ciao, can you take a look at it? -------------- next part...

I do not have a strong opinion on the naming of the various size functions, or on how to deal with APInt's of sizes that are not multiples of a byte. I do think loading and storing more bytes than necessary is generally a bad idea, especially if you're getting uninitialized bits. (If you incorrectly cross a page boundary, you might fault, for one thing. Watch out for packed

...ater. > >> Should (4) be the same as (5) since alloca / malloc are allocating an >> array of the specific type? > > Yes, I think so. Currently alloca allocates a multiple of getTypeSize > (see visitAlloca in SelectionDAGISel). This seems to be a bug - it > needs to use getABITypeSize. This also means that all the (many) > places > that use getTypeSize as the amount of memory allocated by an alloca > need > to be changed... Hrm. It does seem like it could be a bug. I am not too familiar with the code so someone please verify this. Chris? > >>> In...

...used to mean the return type was i32 and the parameter types were (i8*, i8*), but now it means something different (probably that the return type is {i32, i8*, i8*}, but I'm not sure). - BinaryOperator::createAnd -> CreateAnd (and similarly for lots of other createX functions) - TargetData::getABITypeSize -> getTypePaddedSize - APFloat::convertToAPInt -> bitcastToAPInt I don't know if any of these count as "major". Thanks, Jay.

Hi All, Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Let me know if you have any additions, improvements, or see any oversights. If you have commit access, please just directly change the document. The release is planned to go out in about 24 hours from now! Thanks! -Chris

...PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))); + const Type *ATy = cast<PointerType>(ArrayAddr->getType())- >getElementType(); + const Type *ElementTy = cast<ArrayType>(ATy)->getElementType(); + unsigned Alignment = MinAlign(ArrayAlign, TD.getABITypeSize(ElementTy)); + return LValue(BitCastToType(Ptr, + PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))), + Alignment); } // If we are indexing over a fixed-size type, just use a GEP. - if (isSequentialCompatible(ArrayType)) { - const Type...

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

...ment; Couldn't this be expr_align(Array)? > + const Type *ATy = cast<PointerType>(ArrayAddr->getType())- > >getElementType(); > + const Type *ElementTy = cast<ArrayType>(ATy)->getElementType(); > + unsigned Alignment = MinAlign(ArrayAlign, > TD.getABITypeSize(ElementTy)); Why these manipulations? These happens several more times below. > @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB > > LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) { > LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0)); > - tree FieldDecl =...

...; + MachineConstantPoolEntry CPE = Constants.back(); >> + unsigned Size = CPE.Offset; >> + const Type *Ty = CPE.isMachineConstantPoolEntry() >> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); >> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >> >>> getConstantPoolAlignment()); >>> >> + ConstantPool = MCP; >> +} >> + >> +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { >> + const s...

...turn; > + > + MachineConstantPoolEntry CPE = Constants.back(); > + unsigned Size = CPE.Offset; > + const Type *Ty = CPE.isMachineConstantPoolEntry() > + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); > + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); > + ConstantPoolBase = allocateSpace(Size, 1 << MCP- > >getConstantPoolAlignment()); > + ConstantPool = MCP; > +} > + > +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { > + const std::vector<MachineJumpTableEntry> &JT = MJTI- >...

...PE = Constants.back(); >>> + unsigned Size = CPE.Offset; >>> + const Type *Ty = CPE.isMachineConstantPoolEntry() >>> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal- >>> >getType(); >>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>> >>>> getConstantPoolAlignment()); >>>> >>> + ConstantPool = MCP; >>> +} >>> + >>> +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) {...

On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the

...;>> + const Type *Ty = CPE.isMachineConstantPoolEntry() >>>> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal- >>>> >>>>> getType(); >>>>> >>>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>>> >>>> >>>>> getConstantPoolAlignment()); >>>>> >>>>> >>>> + ConstantPool = MCP; >>>> +} >>>&...

...l.MachineCPVal->getType() : CPE.Val.ConstVal- >>>>>> >>>>>> >>>>>>> getType(); >>>>>>> >>>>>>> >>>>>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>>>>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>>>>> >>>>>> >>>>>> >>>>>>> getConstantPoolAlignment()); >>>>>>> >>>>>>> >&gt...

...tRetType = dynamic_cast<const PointerType*>(paramType)->getTypeAtIndex((unsigned)0); const std::string structRetName(M->getTypeName(structRetType)); if (structRetName != "struct.std::string") return 1; // Get object size uint64_t size = EE->getTargetData()->getABITypeSize(structRetType); // Make room on stack void* p = alloca(size); // Create parameter list std::vector<GenericValue> parameters; GenericValue structRetParameter; structRetParameter = PTOGV(p); parameters.push_back(structRetParameter); EE->runFunction(F, parameters); // Cop...

...E.Val.MachineCPVal->getType() : CPE.Val.ConstVal- >>>>>>> >>>>>>> >>>>>>>> getType(); >>>>>>>> >>>>>>>> >>>>>>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>>>>>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> getConstantPoolAlignment()); >>>>>>>> >>>>>>&...

...t;>> + const Type *Ty = CPE.isMachineConstantPoolEntry() >>>>> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal- >>>>> >>>>>> getType(); >>>>>> >>>>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>>>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>>>> >>>>> >>>>>> getConstantPoolAlignment()); >>>>>> >>>>>> >>>>> + ConstantPool = MCP; >>>>> +} &...