This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [RFC]: Remove Mem/address type assumption in combiner
- From: "Kumar, Venkataramanan" <Venkataramanan dot Kumar at amd dot com>
- To: "sellcey at imgtec dot com" <sellcey at imgtec dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, "Jeff Law (law at redhat dot com)" <law at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "maxim dot kuvyrkov at linaro dot org" <maxim dot kuvyrkov at linaro dot org>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, clm <clm at codesourcery dot com>
- Date: Tue, 12 May 2015 05:21:53 +0000
- Subject: RE: [RFC]: Remove Mem/address type assumption in combiner
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is 165.204.84.221) smtp.mailfrom=amd.com; codesourcery.com; dkim=none (message not signed) header.d=none;
- References: <7794A52CE4D579448B959EED7DD0A4723DCF68C1 at satlexdag06 dot amd dot com> <1431366602 dot 14613 dot 210 dot camel at ubuntu-sellcey>
Hi Steve,
Yes this is expected. As Segher pointed out, we need to change .md patterns in target to be based on shifts instead of mults.
Regards,
Venkat.
-----Original Message-----
From: Steve Ellcey [mailto:sellcey@imgtec.com]
Sent: Monday, May 11, 2015 11:20 PM
To: Kumar, Venkataramanan
Cc: Segher Boessenkool; Jeff Law (law@redhat.com); gcc-patches@gcc.gnu.org; maxim.kuvyrkov@linaro.org; Matthew Fortune; clm
Subject: RE: [RFC]: Remove Mem/address type assumption in combiner
On Thu, 2015-05-07 at 11:01 +0000, Kumar, Venkataramanan wrote:
> Hi Segher,
>
> Thank you I committed as r222874.
> Ref: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222874
>
> Regards,
> Venkat.
Venkat,
This patch broke a number of MIPS tests, specifically mips32r6 tests that look for the lsa instruction (load scaled address) which shifts one register and then adds it to a second register. I am not sure if this needs to be addressed in combine.c or if we need to add a peephole optimization to mips.md to handle the new instruction sequence. What do you think? Is the change here what you would expect to see from your patch?
With this C code:
signed short test (signed short *a, int index) {
return a[index];
}
GCC/combine for mips32r6 used to produce:
(insn 8 7 9 2 (set (reg/f:SI 203)
(plus:SI (mult:SI (reg:SI 5 $5 [ index ])
(const_int 2 [0x2]))
(reg:SI 4 $4 [ a ]))) lsa.c:3 444 {lsa}
(expr_list:REG_DEAD (reg:SI 5 $5 [ index ])
(expr_list:REG_DEAD (reg:SI 4 $4 [ a ])
(nil))))
(insn 15 10 16 2 (set (reg/i:SI 2 $2)
(sign_extend:SI (mem:HI (reg/f:SI 203) [1 *_5+0 S2 A16])))
lsa.c:4 237 {*extendhisi2_seh}
(expr_list:REG_DEAD (reg/f:SI 203)
(nil)))
And would generate:
lsa $4,$5,$4,1
lh $2,0($4)
But now it produces:
(insn 7 4 8 2 (set (reg:SI 202)
(ashift:SI (reg:SI 5 $5 [ index ])
(const_int 1 [0x1]))) lsa.c:3 432 {*ashlsi3}
(expr_list:REG_DEAD (reg:SI 5 $5 [ index ])
(nil)))
(insn 8 7 9 2 (set (reg/f:SI 203)
(plus:SI (reg:SI 4 $4 [ a ])
(reg:SI 202))) lsa.c:3 13 {*addsi3}
(expr_list:REG_DEAD (reg:SI 4 $4 [ a ])
(expr_list:REG_DEAD (reg:SI 202)
(nil)))
(insn 15 10 16 2 (set (reg/i:SI 2 $2)
(sign_extend:SI (mem:HI (reg/f:SI 203) [1 *_5+0 S2 A16])))
lsa.c:4 237 {*extendhisi2_seh}
(expr_list:REG_DEAD (reg/f:SI 203)
(nil)))
Which generates:
sll $5,$5,1
addu $4,$4,$5
lh $2,0($4)
Steve Ellcey
sellcey@imgtec.com