Hi Dale,
> The attached patch, plus the bits I've checked in, seems to work.
> There are no problems in the llvm testsuite but there's something
> funny going on in the gcc testsuite, although I'm not convinced it's
> the fault of this patch, so I'm not checking it in until I get that
> f
The attached patch, plus the bits I've checked in, seems to work.
There are no problems in the llvm testsuite but there's something
funny going on in the gcc testsuite, although I'm not convinced it's
the fault of this patch, so I'm not checking it in until I get that
figured out. You cou
> By the way, to be consistent, getTypeSize for an APInt
> should return the number of bits rounded up to a multiple
> of 8, rather than rounded up to a power of 2 as it is now.
> Shall I make this change?
Due to the way ExpandOp works for loads and stores, it looks
like the size needs to be the s
By the way, to be consistent, getTypeSize for an APInt
should return the number of bits rounded up to a multiple
of 8, rather than rounded up to a power of 2 as it is now.
Shall I make this change?
Ciao,
Duncan.
___
llvm-commits mailing list
llvm-commit
Hi Dale,
> I tried having the padding by part of the type but concluded this way is
> better (although there's a bug, see below.)
>
> The idea is that the size represents how many bytes actually have data,
> and the padding in structs and arrays is handled by the alignment (btw,
> size and alignm
I tried having the padding by part of the type but concluded this way is
better (although there's a bug, see below.)
The idea is that the size represents how many bytes actually have data,
and the padding in structs and arrays is handled by the alignment (btw,
size and alignment are both 16 on Dar
Hi Dale, on my machine (x86-32, linux) LLVM considers long double to
have a size of 10 bytes and an alignment of 4 bytes. GCC gives it a
size of 12 bytes and an alignment of 4 bytes (of course only the first
80 bits (10 bytes) are actually used - the rest is padding).
I can see several problems w
