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
