On 2025/07/23 2:16, Max Filippov wrote:
Regtested for target=xtensa-linux-uclibc. Two new regressions in the
configuration
with call0 ABI:
FAIL: gcc.c-torture/execute/20000603-1.c -O2 execution test
FAIL: gcc.c-torture/execute/20000603-1.c -O3 -g execution test
because the load from b->d is now scheduled before the store to a->d:
f:
addi sp, sp, -16
l32r a5, .LC2
s32i.n a0, sp, 12
+ mov.n a9, a2
movi.n a4, 0
- s32i.n a4, a2, 0
- s32i.n a5, a2, 4
- l32r a9, .LC1
l32i.n a2, a3, 0
l32i.n a3, a3, 4
+ s32i.n a4, a9, 0
+ s32i.n a5, a9, 4
+ l32r a9, .LC1
callx0 a9
l32i.n a0, sp, 12
addi sp, sp, 16
ret.n
which may be expected with -O2 and -O3 that enable -fstrict-aliasing.
This "problem" directly stems from the fact that the fifth "type" attribute
was recently added to the "movdf_internal" insn pattern, "load" which allows
for instruction scheduling that was not previously possible.
[(set_attr "type" "move,load,move,load,load,store")
^^^^^
The above conjecture can be further reinforced by replacing "double"s in that
source with "float"s that are also schedulable since before (i.e., SFmode) and
evaluating the results of compiling them. IMHO adding this attribute makes
the behavior of types of the same kind more consistent.
=====
jjsuwa_sys3...@yahoo.co.jp
