Richard Sandiford <rdsandif...@googlemail.com> wrote: >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 stand corrected. Now that's one more argument for infinite precision constants, as the mode is then certainly provided by the operations similar to the sign. That is, the mode (or size, or precision) of 1 certainly does not matter. >>> 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. Not unifying const-int and double-int in the end would be odd. Richard. >Thanks, >Richard
