This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem exposed by recent ARM multiply changes

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]