This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] Use proper output modifier for DImode register in store exclusive patterns
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Wed, 1 Jun 2016 10:07:03 +0100
- Subject: Re: [PATCH][ARM] Use proper output modifier for DImode register in store exclusive patterns
- Authentication-results: sourceware.org; auth=none
- References: <56E01D75 dot 40807 at foss dot arm dot com> <574EA495 dot 20802 at foss dot arm dot com>
On 01/06/16 10:02, Ramana Radhakrishnan wrote:
>
>
> On 09/03/16 12:56, Kyrill Tkachov wrote:
>> Hi all,
>>
>> I notice that the output code for our store exclusive patterns accesses unallocated memory.
>> It wants to output an strexd instruction with a pair of consecutive registers corresponding
>> to a DImode value. For that it creates the SImode top half of the DImode register and puts it
>> into operands[3]. But the pattern only defines entries only up to operands[2], with no match_dup 3
>> or like that, so operands[3] should technically be out of bounds.
>>
>> We already have a mechanism for printing the top half of a DImode register, that's the 'H' output modifier.
>> So this patch changes those patterns to use that, eliminating the out of bounds access and making
>> the code a bit simpler as well.
>>
>> Bootstrapped and tested on arm-none-linux-gnueabihf.
>>
>> Ok for trunk?
>>
>> Thanks,
>> Kyrill
>>
>> 2016-03-09 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>>
>> * config/arm/sync.md (arm_store_exclusive<mode>):
>> Use 'H' output modifier on operands[2] rather than creating a new
>> entry in out-of-bounds memory of the operands array.
>> (arm_store_release_exclusivedi): Likewise.
>
>
> Ok,
>
Ah hang on - is this safe for big-endian - remind me again why we shouldn't use 'Q' and 'R' here ?
Ramana
> Thanks,
> ramana
>