> > What are GET_MODE_BITSIZE and GET_MODE_PRECISION for PSImode?
>
> It *should* be 20 and 20 for msp430. But GET_MODE_BITSIZE returns 32,
> because it's a macro that does GET_MODE_SIZE * BITS_PER_UNIT, so it
> cannot return 20.
No, it should not be 20, mode sizes are multiple of the unit, you'
> > PSImode is 20 bits, fits in a 20 bit register, and uses 20 bit operations.
>
> Then why do you need this change?
Because parts of the gcc code use the byte size instead of the bit
size, or round up, or assume powers-of-two sizes.
> > - TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (
> PSImode is 20 bits, fits in a 20 bit register, and uses 20 bit operations.
Then why do you need this change?
> - TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type)));
> + TYPE_SIZE (type) = bitsize_int (GET_MODE_PRECISION (TYPE_MODE
> (type))); TYPE_SIZE_UNIT (type) =
> which means that the precision of the mode is used to set the size
> of the type, which very likely means that the size of the mode is
> larger. So the size of the mode will be larger than the size of the
> type, which is a lie.
For partial int modes, the precision and size are the same, and
n
> Except gcc now knows the size of partial int modes. In this case,
> PSImode is 20 bits and TYPE_SIZE is 20 bits, so they match.
I don't understand. The problematic change is
> - TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type)));
> + TYPE_SIZE (type) = bitsize_int
> I'm very skeptical... In any case, having a type whose TYPE_SIZE is smaller
> than the size of its MODE is a lie which will bite you back at some point.
Except gcc now knows the size of partial int modes. In this case,
PSImode is 20 bits and TYPE_SIZE is 20 bits, so they match.
The code was
> I don't doubt it, because I've been fighting these assumptions for years.
The fight needs to be resumed/sped up, that's clearly the right thing to do.
> Then please provide a "very good idea" for how to teach gcc about true
> 20-bit types in a system with 8-bit memory and 16-bit words.
TYPE_PR
> Setting TYPE_PRECISION is mostly useless, because most of gcc assumes
> it's the same as TYPE_SIZE and ignores it.
Then you need to change that and not TYPE_SIZE.
> It seems to work just fine in testing, and I'm trying to make it
> non-fundamental.
I'm very skeptical... In any case, having a
> That's what'll need fixing then.
Can I change TYPE_SIZE to TYPE_SIZE_WITH_PADDING then? Because it's
not reflecting the type's size any more. Why do we have to round up a
type's size anyway? That's a pointless assumption *unless* you're
allocating memory space for it, and in that case, you w
On 07/03/2014 06:12 PM, DJ Delorie wrote:
The hardware transfers data in and out of byte-oriented memory in
TYPE_SIZE_UNITS chunks. Once in a hardware register, all operations
are either 8, 16, or 20 bits (TYPE_SIZE) in size. So yes, values are
padded in memory, but no, they are not padded in r
> And the hardware really loads 20 bits and not 24 bits? If so, I
> think you might want to consider changing the unit to 4 bits instead
> of 8 bits. If no, the mode is padded and has 24-bit size so why is
> setting TYPE_PRECISION to 20 not sufficient to achieve what you
> want?
The hardware tr
> Yes. That's exactly the problem I'm trying to solve here. I'm making
> partial int modes have real corresponding types, and they can be any
> bit size, with target PS*modes to match. The MSP430, for example, has
> 20-bit modes, 20-bit operands, and __int20. Rounding up to byte sizes
> forces
> Do you have modes whose size is not multiple of the unit?
Yes. That's exactly the problem I'm trying to solve here. I'm making
partial int modes have real corresponding types, and they can be any
bit size, with target PS*modes to match. The MSP430, for example, has
20-bit modes, 20-bit opera
> The whole point of using _PRECISION is to have the size be exactly the
> same as the mode (bitsize is bigger than the mode for partial-int
> modes). TYPE_SIZE_UNIT should be its storage size, right? If the
> type is not a multiple of BITS_PER_UNIT, the actual size and
> stored-in-memory size ar
> If you find a particular use of TYPE_SIZE is using a size that isn't
> correct for your type whose precision is not a multiple of
> BITS_PER_UNIT, then in my model the correct fix is to change that
> use of TYPE_SIZE rather than to change the value of TYPE_SIZE for
> that type - and such a chang
> Yes; I think that makes sense, unless someone produces a clearer
> definition of what TYPE_SIZE means that isn't redundant.
Does TYPE_SIZE have a different meaning than TYPE_PRECISION
for non-integer types? Floats, vectors, complex?
On Fri, 27 Jun 2014, DJ Delorie wrote:
> Are you proposing we remove TYPE_SIZE completely?
Yes; I think that makes sense, unless someone produces a clearer
definition of what TYPE_SIZE means that isn't redundant.
If you find a particular use of TYPE_SIZE is using a size that isn't
correct for
Are you proposing we remove TYPE_SIZE completely?
On Fri, 27 Jun 2014, DJ Delorie wrote:
> If you still disagree, let's first figure out what the right
> relationship between TYPE_SIZE and TYPE_SIZE_UNIT is, for types that
> aren't a multiple of BITS_PER_UNIT.
My suggestion: TYPE_SIZE should always be TYPE_SIZE_UNIT times
BITS_PER_UNIT, so incl
> No stor-layout.c listed here but...
I knew I'd miss at least one in the split-up...
> > Index: gcc/stor-layout.c
> > ===
> > --- gcc/stor-layout.c (revision 211858)
> > +++ gcc/stor-layout.c (working copy)
> > @@ -2123
> gcc/
> * cppbuiltin.c (define_builtin_macros_for_type_sizes): Round
> pointer size up to a power of two.
> * defaults.h (DWARF2_ADDR_SIZE): Round up.
> (POINTER_SIZE_UNITS): New, rounded up value.
> * dwarf2asm.c (size_of_encoded_value): Use it.
> (dw2_output_i
Part 1 of 4, split from the full patch. The purpose of this set of
changes is to remove assumptions in GCC about type sizes. Previous to
this patch, GCC assumed that all types were powers-of-two in size, and
used naive math accordingly.
Old:
POINTER_SIZE / BITS_PER_UNIT
TYPE_SIZ
22 matches
Mail list logo
