This is the mail archive of the gcc-patches@gcc.gnu.org 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 Fri, Sep 27, 2019 at 10:08:46AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 05:34:25PM -0500, Segher Boessenkool wrote:
> > > Are you sure?
> > > "The UMLAL instruction interprets the values from Rn and Rm as unsigned
> > > integers.  It multiplies these integers, and adds the 64-bit result to the
> > > 64-bit unsigned integer contained in RdHi and RdLo."
> > 
> > Yes.  It adds two 64-bit numbers.  That is not the same as adding the
> > top and bottom 32-bit halfs of that separately.
> 
> Sure.

> But because 131 is shifted <<32 and the result then >>32, we can simplify
> that further to what the pattern uses:
> (set (reg:SI 133 [+4 ])
>     (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI (zero_extend:DI (reg/v:SI 115 [ sec ]))
>                         (zero_extend:DI (reg:SI 124)))
>                     (zero_extend:DI (reg:SI 130)))
>                 (const_int 32 [0x20])))
>         (reg:SI 131 [+4 ])))

I completely missed the (zero_extend (reg:SI 130)) in there.  My excuse
is the messed up formatting in the insn dump.  Sorry for the noise, and
thanks for your patience.

BTW, did you check if GCC optimises to this same formulation?  Say in
combine, can it do combinations of this insn with anything else?


Segher


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