Displaying 4 results from an estimated 4 matches for "gettypesizeinbyt".
Did you mean:
gettypesizeinbits
2007 Oct 08
0
[LLVMdev] The definition of getTypeSize
...o be (3), the maximum number
> of bits that
> may be overwritten by a store [except that it's in bytes]. This
> means changing the
> implementation for APInts, but not for other types.
To me getTypeSize is getTypeSizeInBits divided by 8 and rounded up. I
think renaming it to getTypeSizeInBytes make sense.
>
> Clearly getABITypeSize corresponds to (5) [except that it's in
> bytes]. This
> corresponds to gcc's TYPE_SIZE.
Right.
>
> Currently getABITypeSizeInBits returns 36 for i36, and otherwise
> 8*getABITypeSize.
> It seems to me that this is cle...
2007 Oct 08
3
[LLVMdev] The definition of getTypeSize
...> of bits that
> > may be overwritten by a store [except that it's in bytes]. This
> > means changing the
> > implementation for APInts, but not for other types.
>
> To me getTypeSize is getTypeSizeInBits divided by 8 and rounded up. I
> think renaming it to getTypeSizeInBytes make sense.
Many parts of LLVM are using getTypeSize as the size of an alloca. That
seems to be wrong - I guess they should all be using getABITypeSize. In
that case is getTypeSize useful? I don't see the point of having it be
getTypeSizeInBits rounded up to a multiple of 8. In fact that...
2007 Oct 07
5
[LLVMdev] The definition of getTypeSize
Now that I'm working on codegen support for arbitrary precision
integers (think i36 or i129), I've hit the problem of what
getTypeSize and friends should return for such integers (the
current implementations seem to me to be wrong). However it's
not clear to me how getTypeSize and friends are defined.
There seem to be several possible meanings for the size of a type
(only talking
2007 Oct 09
0
[LLVMdev] The definition of getTypeSize
...at
>>> may be overwritten by a store [except that it's in bytes]. This
>>> means changing the
>>> implementation for APInts, but not for other types.
>>
>> To me getTypeSize is getTypeSizeInBits divided by 8 and rounded up. I
>> think renaming it to getTypeSizeInBytes make sense.
>
> Many parts of LLVM are using getTypeSize as the size of an alloca.
> That
> seems to be wrong - I guess they should all be using
> getABITypeSize. In
> that case is getTypeSize useful? I don't see the point of having
> it be
> getTypeSizeInBits...