This is the mail archive of the
mailing list for the GCC project.
Re: [lra] Cleanup the use of offmemok and don't count spilling cost for it
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Jiong Wang <jiong dot wang at foss dot arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, vogt at linux dot vnet dot ibm dot com, Jeff Law <law at redhat dot com>, Vladimir N Makarov <vmakarov at redhat dot com>, Robin Dapp <rdapp at linux dot vnet dot ibm dot com>
- Date: Mon, 4 Jul 2016 19:40:44 +0200
- Subject: Re: [lra] Cleanup the use of offmemok and don't count spilling cost for it
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <20160627162614.GA30612@linux.vnet.ibm.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 07/04/2016 04:05 PM, Jiong Wang wrote:
And the corresponding s390 patten is "mov<mode>" for V_128.
[(set (match_operand:V_128 0 "" "=v,v,R, v, v, v, v, v,v,d")
(match_operand:V_128 1 "" "v,R,v,j00,jm1,jyy,jxx,jKK,d,v"))]
As the offset "-16" does not qualify s390_short_displacement, we need a
Ideally we want alternative 2, for which gcc simply reload the mem
address into a address register.
While after r237277, gcc is treating the reload of insn 41 as a spill
and thus increased the costs for it, then alternative 8 beat alternative
2, thus the following reload sequences are generated.
GCC move the vector register into general register, then a second
instruction to store the general register into memory so it can match
alternative 8, which is "v", "d".
However the second instructions still constains the illegal mem address,
thus a further reload triggered, and gcc triggers above max number
The functional chang of this patch is to make gcc don't treat an memory
address reload as spill which is regression caused by r237277.
Does this explanation make sense?
Yes, it explains well what's going on. I think the part of your patch
that avoids counting a reload of an address as a spill looks ok. I'm
uncertain whether the code still has issues after that, it seems a
little iffy not to count the cost of reloading the memory address at
all. We might have to add code at some point to detect if we're
reloading a move instruction and would be generating an identical one
when picking a given alternative.