patch to fix constant math

[Richard Sandiford]

Richard Guenther <richard.guenther@gmail.com> writes:
>> As far as the wide_ints recording a mode or precision goes: we're in
>> the "lucky" position of having tried both options.  Trees record the
>> type (and thus precision) of all compile-time integer constants.
>> RTL doesn't.  And the RTL way is a right pain.  It leads to interfaces
>> in which rtx arguments often have to be accompanied by a mode.  And it
>> leads to clunky differences like those between simplify_unary_operation
>> (which takes two mode arguments) and simplify_binary_operation
>> (which with our current set of binary operations requires only one).
>
> But the issue here is not that double_int doesn't record a mode
> or precision (or a sign).  The issue is that CONST_DOUBLE and CONST_INT
> don't!  The _tree_ INTEGER_CST contains of a type and a double-int.
> I see double-int (and the proposed wide-int) as a common building-block
> used for kind of "arbitrary precision" (as far as the target needs) integer
> constants on both tree and RTL.  And having a common worker implementation
> requires it to operate on something different than tree types or RTL mode
> plus signedness.
>
>> To put it another way: every wide_int operation needs to know
>> the precision of its arguments and the precision of its result.
>
> That's not true.  Every tree or RTL operation does, not every
> wide_int operation.  double_int's are just twos-complement numbers
> of precision 2 * HOST_BITS_PER_WIDE_INT.  wide_int's should
> be just twos-complement numbers of precision len *
> WHATEVER_HOST_COMPONENT_TYPE_IS_SUITABLE_FOR_A_FAST_IMPLEMENTATION.
> Operations on double_int and wide_int are bare-metal,
> in nearly all of the times you should use routines that do
> proper sign-/zero-extending to a possibly smaller precision.  When
> using bare-metal you are supposed to do that yourself.
>
> Which is why I was suggesting to add double_sint, double_uint,
> double_sintp (with precision), etc., wrappers and operations.
>
>> Not storing the precision in the wide_int is putting the onus
>> on the caller to keep track of the precision separately.
>
> But that's a matter of providing something high-level ontop of
> the bare-metal double-int/wide-int (something shared between
> RTL and trees).  Duplicating information in the bare-metal
> doesn't make sense (and no, INTEGER_CSTs on the tree level
> are _not_ short-lived, and how can a double-int make sense on
> the tree level when you say it doesn't make sense on the RTL level?)

I think we're talking at cross purposes here.  To the extent that
I'm not really sure where to begin. :-)  Just in case this is it:
the idea is that wide_int is the type used to _process_ integers.
It is not suppoed to be the type used to store integers in the IRs.
The way trees store integers and the way that RTL stores integers
are up to them.  For RTL the idea is that we continue to store integers
that happen to fit into a HWI as a CONST_INT (regardless of the size of
the CONST_INT's context-determined mode).  Wider integers are stored
as a CONST_DOUBLE (for unconverted targets) or a CONST_WIDE_INT
(for converted targets).  None of the three use the wide_int type;
they use more compact representations instead.  And as Kenny says,
using CONST_INT continues to be an important way of reducing the
IR footprint.

Whenever we want to do something interesting with the integers,
we construct a wide_int for them and use the same processing code
for all three rtx types.  This avoids having the separate single-HWI
and double-HWI paths that we have now.  It also copes naturally with
cases where we start out with single-HWI values but end up with wider
ones.

But the operations that we do on these wide_ints will all be to a mode
or precision.  Shifts of QImode integers are different from shifts of
HImode integers, etc.

If you knew all that already (you probably did) and I've completely
missed the point, please say so. :-)

I'm not sure what you mean by "bare metal".

Richard