This is the mail archive of the
mailing list for the GCC project.
Re: [ARM] Fix build failure due to movsi_compare0 (PR 61430)
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>, gcc-patches at gcc dot gnu dot org
- Cc: richard dot earnshaw at arm dot com, ramana dot radhakrishnan at arm dot com
- Date: Fri, 13 Jun 2014 12:46:45 -0400
- Subject: Re: [ARM] Fix build failure due to movsi_compare0 (PR 61430)
- Authentication-results: sourceware.org; auth=none
- References: <1402482739-4549-1-git-send-email-james dot greenhalgh at arm dot com> <53988F3B dot 20509 at codesourcery dot com>
On 2014-06-11, 1:17 PM, Chung-Lin Tang wrote:
> On 2014/6/11 下午 06:32, James Greenhalgh wrote:
>> A recent change somewhere exposed a latent bug between LRA and the definition
>> of the movsi_compare0 pattern.
>> This pattern ties the source and destination register of a set together
>> a (match_dup) and register constraints:
>> [(set (reg:CC CC_REGNUM)
>> (compare:CC (match_operand:SI 1 "s_register_operand" "0,r")
>> (const_int 0)))
>> (set (match_operand:SI 0 "s_register_operand" "=r,r")
>> (match_dup 1))]
>> This confuses LRA which expects the source and destination register of
>> a set to be different.
>> reduced.c: In function '_IO_vfscanf_internal':
>> reduced.c:104:1: internal compiler error: in lra_create_copy, at lra.c:1512
>> 0x8c3f9a lra_create_copy(int, int, int)
>> 0x8e4ab0 process_bb_lives
>> 0x8e4ab0 lra_create_live_ranges(bool)
>> 0x8c5a39 lra(_IO_FILE*)
>> 0x873a96 do_reload
>> 0x873a96 execute
>> Please submit a full bug report,
>> We can fix the pattern by moving away from match_dup and using register
>> tying with constraints consistently.
>> I'm not entirely convinced that this is legitimate (my vague recollection is
>> that register tying should only be used to tie inputs to outputs).
>> This has passed testing on a bunch of ARM targets, and fixes the build
>> issues I've been seeing.
> Looking at this too, as an LRA exercise. I don't really think the
> pattern is wrong, rather LRA should just avoid creating the copy in this
> case; it's a result of operand constraining, after all.
> Attached is the small LRA patch, pending testing. Vladimir should weight
> in on this.
The patch is safe and ok. Thanks for working on it, Chung-Lin.
> * ira-lives.c (process_bb_lives): Skip creating copy during
> insn sca when src/dest has constrained to same regno.