Richard Biener <richard.guent...@gmail.com> writes:
>> At the rtl level your idea does not work.   rtl constants do not have a mode
>> or type.
>
> Which is not true and does not matter.  I tell you why.  Quote:

It _is_ true, as long as you read "rtl constants" as "rtl integer constants" :-)

> +#if TARGET_SUPPORTS_WIDE_INT
> +
> +/* Match CONST_*s that can represent compile-time constant integers.  */
> +#define CASE_CONST_SCALAR_INT \
> +   case CONST_INT: \
> +   case CONST_WIDE_INT
>
> which means you are only replacing CONST_DOUBLE with wide-int.
> And _all_ CONST_DOUBLE have a mode.  Otherwise you'd have no
> way of creating the wide-int in the first place.

No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT.
Only floating-point CONST_DOUBLEs have a "real" mode.

>> I understand that this makes me vulnerable to the argument that we should
>> not let the rtl level ever dictate anything about the tree level, but the
>> truth is that a variable len rep is almost always used for big integers.
>> In our code, most constants of large types are small numbers.   (Remember i
>> got into this because the tree constant prop thinks that left shifting any
>> number by anything greater than 128 is always 0 and discovered that that was
>> just the tip of the iceberg.) But mostly i support the decision to canonize
>> numbers to the smallest number of HWIs because most of the algorithms to do
>> the math can be short circuited.    I admit that if i had to effectively
>> unpack most numbers to do the math, that the canonization would be a waste.
>> However, this is not really relevant to this conversation.   Yes, you could
>> get rid of the len, but this such a small part of picture.
>
> Getting rid of 'len' in the RTX storage was only a question of whether it
> is an efficient way to go forward.  And with considering to unify
> CONST_INTs and CONST_WIDE_INTs it is not.  And even for CONST_WIDE_INTs
> (which most of the time would be 2 HWI storage, as otherwise you'd use
> a CONST_INT) it would be an improvement.

FWIW, I don't really see any advantage in unifying CONST_INT and
CONST_WIDE_INT, for the reasons Kenny has already given.  CONST_INT
can represent a large majority of the integers and it is already a
fairly efficient representation.

It's more important that we don't pick a design that forces one
choice or the other.  And I think Kenny's patch achieves that goal,
because the choice is hidden behind macros and behind the wide_int
interface.

Thanks,
Richard

Reply via email to