This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check
- From: Nikolai Bozhenov <nikolai dot bozhenov at gmail dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>
- Date: Fri, 6 Nov 2015 20:07:50 +0300
- Subject: Re: Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check
- Authentication-results: sourceware.org; auth=none
- References: <56309E44 dot 8070100 at arm dot com> <563C9C7F dot 3040402 at samsung dot com> <563CAF46 dot 2060303 at foss dot arm dot com>
On 11/06/2015 04:46 PM, Ramana Radhakrishnan wrote:
Hi!
I faced the same issue but I had somewhat different RTL for the consumer:
(insn 20 15 21 2 (set (reg/i:SI 0 r0)
(minus:SI (subreg:SI (reg:DI 117) 4)
(mult:SI (reg:SI 123)
(reg:SI 114)))) gasman.c:4 48 {*mulsi3subsi})
where (reg:DI 117) is produced by umulsidi3_v6 instruction. Is it
really true that (subreg:SI (reg:DI 117) 4) may be forwarded in one
cycle in this case?
If the accumulator can be forwarded (i.e. a SImode register), there isn't a reason why a subreg:SI (reg:DI) will not get forwarded.
The subreg:SI is an artifact before register allocation, thus it's a representation issue that the patch is fixing here unless I misunderstand your question.
I mean, in my example it is not the multiplication result that is
forwarded but its upper part. So, shouldn't we check that offset in a
subreg expression is zero? Or is it ok to forward only the upper part
of a multiplication?
Thanks,
Nikolai