On 9/26/19 10:05 AM, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 10:01:56AM -0600, Jeff Law wrote:
>> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
>>> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
>>>> Right. My point is that the multiplication patterns are an exception as
>>>> well.
>>>
>>> Do you have some evidence for that?
>> It's in the manual. And yes it potentially makes a huge mess due to the
>> interactions with modeless CONST_INTs.
>
> Where?
> Unless otherwise specified, all the operands of arithmetic expressions
> must be valid for mode @var{m}. An operand is valid for mode @var{m}
> if it has mode @var{m}, or if it is a @code{const_int} or
> @code{const_double} and @var{m} is a mode of class @code{MODE_INT}.
>
> and for MULT:
> Represents the signed product of the values represented by @var{x} and
> @var{y} carried out in machine mode @var{m}.
> @code{ss_mult} and @code{us_mult} ensure that an out-of-bounds result
> saturates to the maximum or minimum signed or unsigned value.
>
> Some machines support a multiplication that generates a product wider
> than the operands. Write the pattern for this as
>
> @smallexample
> (mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y}))
> @end smallexample
>
> where @var{m} is wider than the modes of @var{x} and @var{y}, which need
> not be the same.
^^^ this clause. I read this as x & y being able to vary relative to
each other. But I think you're reading it as x & y are the same, but
they can vary relative to m
Jeff
