Displaying 4 results from an estimated 4 matches for "type_precision".
2007 Oct 07
5
[LLVMdev] The definition of getTypeSize
....
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 suggests it returns 8*getTypeSize. If no one
objects, I will rename it to getBitsUsedByType.
Currently getTypeSize doesn't seem to correspond to any of these possibilities,
at least for APInt'...
2007 Oct 08
0
[LLVMdev] The definition of getTypeSize
...ABITypeSizeInBits 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 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 suggests it returns 8*getTypeSize. If no one
> objects, I will rename it to getBitsUsedByType.
Isn't it the other way around? Type information should be specified
in bits, no...
2007 Oct 08
3
[LLVMdev] The definition of getTypeSize
...e that getTypeSize would have to be
strictly bigger than getTypeSizeInBits rounded up to a multiple of 8...
How does this work for i8 on such machines?
> > 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 suggests it returns 8*getTypeSize. If no one
> > objects, I will rename it to getBitsUsedByType.
>
> Isn't it the other way around? Type information sho...
2007 Oct 09
0
[LLVMdev] The definition of getTypeSize
...nes?
I dunno. I don't think llvm can codegen for such a machine. Maybe
it's worth worrying about it at this point?
>
>>> 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 suggests it returns 8*getTypeSize. If no
>>> one
>>> objects, I will rename it to getBitsUsedByType.
>>
>> Isn't it the other...