This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: [PATCH] MIPS: Implement built-in atomic memory operations.
David Daney <ddaney@avtrex.com> writes:
> Richard Sandiford wrote:
>>> +(define_insn "store_contidional<mode>"
>>> + [(set (match_operand:GPR 0 "memory_operand" "=o")
>>> + (match_operand:GPR 1 "register_operand" "d"))
>>> + (set (match_operand:GPR 2 "register_operand" "=1")
>>> + (unspec_volatile:GPR [(const_int 0)] UNSPEC_SC))]
>>> + "ISA_HAS_LL_SC"
>>> + "sc<d>\t%1,%0"
>>> + [(set_attr "type" "store")
>>> + (set_attr "mode" "<MODE>")]
>>>
>>
>> Same here. But... I worry about the safety of splitting the instructions
>> up like this. The result of the ll/sc pair is not predictable if we stick
>> a load between them,
> Just for the sake of argument: Both load_linked and store_conditional
> are unspec_volatile, the compiler will not be putting anything between
> them we don't emit ourselves. It seems that the expander could assure
> that all operands were either in registers or immediate constants before
> emitting insns between load_linked and store_conditional.
Sorry, I'd forgotten that they were unspec_volatile. But even so,
that isn't a complete guarantee. Let's say the pseudo register in
the "sc" address is P, and consider the case where the P is not
allocated a hard register. If P is equivalent to a constant C
throughout the function, reload will load C immediately before the "sc".
And that load of C might involve a memory access; it might be a GOT load,
or a load from the constant pool. And if P is instead spilled to the stack,
reload will insert a load from the stack immediately before the "sc".
When optimisation is enabled, reload will often be able to inherit
the reload for the "ll", but that isn't guaranteed, and doesn't help
when not optimising.
>> and what's to stop the compiler from inserting a
>> load from read-only memory?
>>
> That is not a problem unique to ll/sc is it? Presumable there would be
> some sort of fault and something like SIGSEGV or SIGBUS would be generated.
Well, this is moot given the unspec_volatile thing, but I was talking
about loads that are known not to trap, or (when -fnon-call-exceptions
is off) loads that postdominate this operation.
Richard