clang arbitrary-width integer types don't calculate size/alignment correctly

[efriedma-quic]

Bugzilla Link	3568
Resolution	WONTFIX
Resolved on	Aug 08, 2010 01:46
Version	unspecified
OS	Linux

Extended Description

I added support for arbitrary-width integer types in r64434. The one known bug in the implementation is that Sema doesn't calculate the size/alignment consistently with LLVM. (And for 128-bit integers, it calculates the alignment to be 128 bits, which as far as I know is not consistent with gcc's TImode.)

LLVM logic for determining the size/alignment:
If there is at least one known integer type whose bitwidth is equal to or larger than the bitwidth of the given integer type, the alignment is that of the smallest such type. Otherwise, the alignment is the alignment of the largest known integer type. The size is then the bitwidth plus whatever padding is necessary to satisfy the alignment.

What makes this non-trivial is that TargetInfo doesn't expose a list of integer types outside of the target description string, and it's definitely too much work to parse the target description.

[efriedma-quic]

Slight correction: clang is actually calculates the alignment for 128-bit integers consistently with gcc, at least on x86-64. It looks like LLVM actually computes the alignment incorrectly! Although, it probably doesn't cause any visible issues for llvm-gcc...

[llvmbot]

So an i128 is 16 byte aligned on x86-64? That doesn't make much sense
to me... By the way, I don't think it matters if gcc and LLVM have
different values for integer alignment, as long as they have always
give integers the same sizes. I actually tested this the other day:
using bitfields you can get gcc to generate integers of any size (see
test/FrontendC/2008-01-07-UnusualIntSize.c), and I checked that LLVM
and gcc agree on the sizes of all integers from i1 ... i64.

[llvmbot]

The following algorithm would be slightly more optimal I think:

(1) if the size of the integer is smaller than the smallest
known integer type, use the alignment of that smallest integer.
(2) if the size of the integer is larger than the largest
known integer type, use the alignment of that largest integer.
(3) if the size of the integer is that of a known integer type,
use the known alignment.
(4) otherwise the size of the integer is between the sizes of
two known integer types A < size < B. Use the alignment of A.

This only differs from the current situation for case (4)
where currently we use the alignment of B. Consider for
example i24 on x86-32. This new scheme would give it an
alignment of 2 bytes, while the old would give it 4 bytes.
The padded size of the integer won't change (still 4 bytes).
The advantage of 2 byte alignment is that i24 stores store
an i16 followed by an i8. Thus "i24 = { i16, i8 }", and 2 byte
alignment is good enough (best to have a smaller alignment
if possible).

[efriedma-quic]

Arbitrary-width integer types were removed because they were unused.