https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64974
Bug ID: 64974
Summary: [SH] Weird expansion of 'expected' operand in
atomic_compare_and_swap<mode>
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
While working on PR 64661, I've noticed that the expansion of the
atomic_compare_and_swap<mode> pattern's 'expected value' operand seems to be
weird.
When compiling with -m4a -matomic-model=hard-llcs -O2, the 'expected value' and
'new value' can be immediate operands in the range -128..+127, if the atomic is
SImode.
The following example function:
void
test_0 (int* mem)
{
int expected = 1;
int desired = 5;
__atomic_compare_exchange (mem, &expected, &desired, 0, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED);
}
is expanded to:
(insn 11 10 12 2 (parallel [
(set (reg:SI 167)
(unspec_volatile:SI [
(mem/v:SI (reg/v/f:SI 162 [ mem ]) [-1 S4 A32])
>>>>> (reg:SI 166)
>>>>> (const_int 5 [0x5])
] UNSPECV_CMPXCHG_1))
(set (mem/v:SI (reg/v/f:SI 162 [ mem ]) [-1 S4 A32])
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (reg:SI 0 r0))
]) sh_tmp.cpp:9 -1
(nil))
While the 'new value' operand is successfully passed as an immediate value, the
'expected value' is not and ends up being written onto the stack. After
various RTL passes combine manages to plug the const_int 1 into the operand and
the stack write is eliminated. However, the stack frame setup remains.
