On Feb 13, 2015, at 1:47 PM, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote:
> > On 13/02/15 10:10, pins...@gmail.com wrote: >> >> >> >>> On Feb 13, 2015, at 1:48 AM, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: >>> >>> Hi all, >>> >>> In my tree added a pattern to the arm backend that's supposed to match: >>> (set (reg:SI r0) >>> (subreg:SI >>> (plus:DI >>> (mult:DI (sign_extend:DI (reg:SI r1)) >>> (sign_extend:DI (reg:SI r2))) >>> (const_int 2147483648 [0x80000000])) 4)) >>> >>> That is, take two SImode regs, sign-extend to DImode, multiply in DImode, >>> add a const_int and take the most significant SImode subreg. >> Seems better to use shifts for the most significant simode and low part >> subreg after that. Isn't that what other targets do? > > I thought about that, but combine tries to match: > (set (reg/i:SI 0 r0) > (subreg:SI (plus:DI (mult:DI (sign_extend:DI (reg:SI 0 r0 [ a ])) > (sign_extend:DI (reg:SI 1 r1 [ b ]))) > (const_int 2147483648 [0x80000000])) 4)) > > > Looking at the RTL dumps all shifts are gone by the time combine is reached > (in this case cse1 removes the shifts) FYI, (and not related to the core issue of this patch) The use of mult vs shift by combine is a problem that Venkat is working on, see "[RFC] Tighten memory type assumption in RTL combiner pass" . The combiner uses MULTs instead of SHIFTs for rtx'es that look like addresses, even when they are, in fact, mere logic/arithmetic operations. -- Maxim Kuvyrkov www.linaro.org
