This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 17/50] df-problems.c:find_memory
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "rdsandiford at googlemail dot com" <rdsandiford at googlemail dot com>
- Date: Wed, 06 Aug 2014 09:35:35 +0100
- Subject: Re: [PATCH 17/50] df-problems.c:find_memory
- Authentication-results: sourceware.org; auth=none
- References: <87y4v5d77q dot fsf at googlemail dot com> <87wqapacyp dot fsf at googlemail dot com> <53E14CB2 dot 1030409 at redhat dot com>
On 05/08/14 22:29, Jeff Law wrote:
> On 08/03/14 08:02, Richard Sandiford wrote:
>> This also fixes what I think is a bug: find_memory used to stop at the
>> first MEM it found. If that MEM was nonvolatile and nonconstant, we'd
>> return MEMREF_NORMAL even if there was another volatile MEM.
>>
>>
>> gcc/
>> * df-problems.c: Include rtl-iter.h.
>> (find_memory): Turn from being a for_each_rtx callback to being
>> a function that examines each subrtx itself. Continue to look for
>> volatile references even after a nonvolatile one has been found.
>> (can_move_insns_across): Update calls accordingly.
> OK.
>
> It'd probably be fairly difficult to test for that bug as most of our
> targets don't allow multiple memory operands in a single insn. But I
> agree with your assessment. Good catch.
>
> jeff
>
>
ARM (and AArch64) have patterns with multiple MEMs; but the mems have to
be related addresses and (I think) be non-volatile (certainly if
volatile is permitted in one MEM it must also be in the others within
the pattern). Patterns generally enforce all of this through the
pattern itself, the constraints or the condition on the insn.
R.