Hi Vlad,
On Fri, Feb 08, 2019 at 02:18:40PM -0500, Vladimir Makarov wrote:
> Recently I committed a patch solving
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
>
> The patch resulted in test vsx-simode2.c failure. Here is the
> difference in generated code:
>
> @@ -13,9 +13,8 @@ foo:
> .LFB0:
> .cfi_startproc
> std 3,-16(1)
> - ori 2,2,0
> - lwz 9,-12(1)
> - mtvsrwz 32,9
> + addi 9,1,-12
> + lxsiwzx 32,0,9
>
> The new version is one insn less. So I propose the following patch
> changing the expected code generation.
>
> Is it ok to commit it?
This is not okay. The test is supposed to test that we get a direct
move instruction instead of going via memory. But, trunk does the
std+lwz as you see; this is because IRA decides this pseudo needs to
go to memory:
r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS
a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004
LINK_REGS:24010,24010 CTR_REGS:24010,24010 LINK_OR_CTR_REGS:24010,24010
SPEC_OR_GEN_REGS:24010,24010 MEM:12000,12000
Is there something wrong in our tuning?
For reference, 7 and 8 do just
mtvsrwz 32,3
#APP
# 10 "vsx-simode2.c" 1
xxlor 32,32,32 # v, v constraints
# 0 "" 2
#NO_APP
mfvsrwz 3,32
blr
which is the expected code. The test really should check there is no
memory used, or that there are no extra insns other than the 4 expected.
Your patch seems to be fine btw, this breakage was really there already,
just not detected by the testcase.
Segher
