[4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

[Richard Henderson <rth at redhat dot com>]

On 02/28/2012 07:16 AM, Oleg Endo wrote:
> Wouldn't it make sense to use the value behind
> TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in optabs.c
> (expand_atomic_test_and_set) instead of const1_rtx when emitting
> generated atomic_exchange / atomic_compare_and_swap_exchange_loop?
> Maybe something like the attached patch?
> 
> Background:
> I'm working on a patch to add a new option -menable-tas (independent of
> the existing -msoft-atomic option) which would allow the compiler to
> generate SH's tas.b insn.  This would allow using the tas.b insn without
> the other atomic sequences, or in combination with them.  The reason
> behind this is that the tas.b insn might not always be appropriate to
> use, depending on the particular system hardware/software setup (e.g.
> dual-core SH4A).
> On SH the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL has to be defined as 0x80.
> Having the generated atomic_compare_and_swap / atomic_exchange sequences
> using 0x01 as the 'set' value might lead to inconsistencies when mixing
> code that uses the tas.b insn and code that doesn't use it, which should
> actually be OK to do.

That's a good idea.

For proper binary compatibility, we should probably introduce that asap.
You forgot two things in your patch, gen_int_mode and the fact that we
still have to return a boolean (0/1) value.

Also in order for the binary compatibility to work right, you'd want to
have the SH test-and-set-trueval set appropriately asap.  Kaz, I assume
you'd agree that 0x80 is a good value for the "tas.b" insn?  We don't
necessarily need to support tas.b right away, but getting trueval set
right is imperative.

I'm in the process of sanity testing this on x86_64 with trueval set to 0x80.
Jakub, ok for 4.7 branch if it passes?


r~

Attachment: z
Description: Text document