search for: bit_size

...ie) && (block_split == false);) { IntrinsicInst *ii = dyn_cast<IntrinsicInst>(&*i); ++i; if(ii) { switch (ii->getIntrinsicID()) { case Intrinsic::objectsize: { IRBuilder<> builder(ii->getParent(), ii); Value *op1 = ii->getArgOperand(0); //i8* uint64_t bit_size = op1->getType()->getPointerElementType()->getPrimitiveSizeInBits(); Value *result = ConstantInt::get(ii->getType(), bit_size); ii->replaceAllUsesWith(result); ii->removeFromParent(); delete ii; break; } } } I'm new to LLVM and not sure whether the implement...

...Etch on AMD64 platform Linux and Solaris running in a HVM domU but they both seem to be 32bit environments. I know so because 64bit Linux didnt boot and said something about am I trying to run it in 32 bit environment; and because i had to install 32bit Oracle because 64bit Oracle said it expected BIT_SIZE=64 and got BIT_SIZE=32. And also, to have under Solaris more than 4GB RAM i needed to add into domU config ''pae=1'' option. Please tell me if there is a way to make HVM 64bit? Best regards, Imre Oolberg PS And also, could somebody explain to me how is this so that in domU witc...

...{ > IntrinsicInst *ii = dyn_cast<IntrinsicInst>(&*i); > ++i; > if(ii) { > switch (ii->getIntrinsicID()) { > case Intrinsic::objectsize: { > IRBuilder<> builder(ii->getParent(), ii); > Value *op1 = ii->getArgOperand(0); //i8* > uint64_t bit_size = op1->getType()->getPointerElementType()->getPrimitiveSizeInBits(); > > First, you can't always determine the size. Just looking at the pointer > element type isn't enough. This requires finding the object definition, > which can fail, and the existing handling uses...

That was essentially part of my question. The DWARF standard says: If the value of an object of the given type does not fully occupy the > storage described by a byte size attribute, the base type entry may also > have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose > values are integer constant values (see Section 2.19). The bit size > attribute describes the actual size in bits used to represent values of the > given type. The data bit offset attribute is the offset in bits from the > beginning...

...airly flexible & >> doesn't dictate "right" answers, as such. >> >> This time, actually the "right" answer is fairly clear (and in normative >> text, no less) right there in section 5.1. Use DW_AT_byte_size for the >> storage size and DW_AT_bit_size for the value size. >> > > I'm not sure - it seems like a valid interpretation to believe that the > value is 128 bits - some of those bits are always zero. (& of course the > DWARF spec says "the base type entry /may/ also have", because it's all > permis...

On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively

...ht have to special case this in the verifier, but before we do that, I wanted to ask about the following: Reading the DWARF standard, it seems like the following would be a valid description of an X86 80bit long double: DW_TAG_base_type DW_AT_name "long double" DW_AT_byte_size 16 DW_AT_bit_size 80 As far as I can tell from looking through the source code, both LLDB and GDB would read this just fine, it would be a more accurate description of a long double and if we add support for it in LLVM IR, the verifier would be able to understand what's actually going on. Does this seem li...