This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/3] Add XLP-specific atomic instructions and tweaks.


Richard Henderson <rth@redhat.com> writes:
> On 2012-06-16 00:45, Richard Sandiford wrote:
>> 	 [(mem:GPR (match_operand:P 1 "register_operand" "d"))]
>> 
>>    Instead, we should define a new memory predicate/constraint pair
>>    for memories that only accept register addresses.  I.e. there
>>    should be a new predicate to go alongside things like
>>    memory_operand and stack_operand, except that the new one would
>>    be even more restrictive in the set of addresses that it allows.
>>    mem_reg_operand seems as good a name as any, but I'm not wedded
>>    to a particular name.
>
> C.f. mem_noofs_operand inthe ARM port, and its uses in sync.md.
>
>>    The atomic_exchange and atomic_fetch_add expanders should use
>>    the code I quoted in the earlier message to force the original
>>    memory_operand into this more restrictive form:
>> 
>>     if (!mem_reg_operand (operands[1], <MODE>mode))
>>       {
>>         addr = force_reg (Pmode, XEXP (operands[1], 0));
>>         operands[1] = replace_equiv_address (operands[1], addr);
>>       }
>
> Not required if you use the proper predicate in the expander.
> The middle-end will take care of this for you.

I might be misunderstanding, sorry, but this expander is shared with
the normal LL/SC path, which can accept plain memory_operands.
I was thinking we'd want to keep the expander predicates the same
and apply these SWAP-style restrictions only when needed.

I suppose we could define a predicate that's equivalent to
mem_reg_operand when ISA_HAS_SWAP and to memory_operand otherwise
(and maybe do the same for arith_operand vs. register_operand
in point (2)).  That might get confusing though.  E.g. Maxim
has kept the ISA flags for SWAP and LDADD separate, which seems
like a good thing.  We'd then need another pair of predicates
for the LDADD case.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]