Re: patch to fix constant math -5th patch, rtl

[Richard Sandiford <rdsandiford@googlemail.com>]

Richard Biener <richard.guenther@gmail.com> writes:
>> But storing the mode in the rtx is orthogonal to what Kenny is doing.
>> The mode of each rtx constant is already available in the places
>> that Kenny is changing, because we already do the work to keep track
>> of the mode separately.  Being able to get the mode directly from the
>> rtx would be simpler and IMO better, but the semantics are the same
>> either way.
>
> Well, you showed examples where it is impossible to get at the mode.

No, I showed examples where the mode is not inherent in the rtl.
That's a very different thing.  I wrote that in respnose to:

Richard Biener <richard.guenther@gmail.com> writes:
> Ok, so what wide-int provides is integer values encoded in 'len' HWI
> words that fit in 'precision' or more bits (and often in less).  wide-int
> also provides N-bit arithmetic operations.  IMHO both are tied
> too closely together.  A give constant doesn't really have a precision.
> Associating one with it to give a precision to an arithmetic operation
> looks wrong to me and are a source of mismatches.
>
> What RTL currently has looks better to me - operations have
> explicitely specified precisions.

That is, you seemed to be arguing that constants don't need a precision
because, whenever you do anything with them, the operator tells you
what precision the constant has.  And you seemed to be citing rtl
as proof of that.

What I was trying to show is that the operator _doesn't_ tell you the
precision in all cases.  Instead, the operands always have their own
precision, and there are rules about which combinations of operand and
operator precision are allowed.  For most binary operations the three
precisions have to be the same.  For things like popcount there's no
real restriction: the precision of the thing being counted and the
precision of the result can be arbitrarily different.  For things like
zero_extend the operator precision must be greater than the operand
precision.  Etc.

The onus is then on the rtl code to keep track of both the operator
and operand precisions where necessary.  _And the current rtl code
already tries to do that_[*].  The cselib example I gave is one place
where we take special measures.  See also things like:

  /* Now recursively process each operand of this operation.  We need to
     handle ZERO_EXTEND specially so that we don't lose track of the
     inner mode.  */
  if (GET_CODE (x) == ZERO_EXTEND)
    {
      new_rtx = make_compound_operation (XEXP (x, 0), next_code);
      tem = simplify_const_unary_operation (ZERO_EXTEND, GET_MODE (x),
					    new_rtx, GET_MODE (XEXP (x, 0)));
      if (tem)
	return tem;
      SUBST (XEXP (x, 0), new_rtx);
      return x;
    }

in combine.c, which is there specifically because this code still knows
the mode of both the operand and operator.

So all this was trying to dispel the idea that:

(a) rtl constants don't have a mode
(b) the mode of an operator tells you the mode of the operands

Neither is really true.  Instead, every rtl constant has a precision/mode.
Every tree constant likewise has a precision.  The main purpose of wide_int
is to handle compile-time arithmetic on rtl constants and tree constants,
and if both of those have a precision, it seems strange that wide_int
shouldn't.  It just pushes the onus of tracking the precision onto the
callers, like the current rtl representation does.  And the examples
I've been giving were supposed to show what a hassle that can be.

  [*] Highlighted because that's why storing a mode in a CONST_INT or
      CONST_DOUBLE isn't a prerequisite for Kenny's patch.  The mode
      is already to hand where it needs to be.

Thanks,
Richard