> You didn't show us the source code, but this is not necessarily a case
> that -fstrict-aliasing will affect. If the two pointers have the same
> type, then it doesn't matter whether you use -fstrict-aliasing or not.
> A store through a int* pointer can change the value read from a int*
> pointer. The compiler can only move the read before the store if it
>can prove that the pointers do not point to the same part of memory.
> You haven't showed us any source code, so I don't know whether this is
> a possible problem or not. I'm just suggesting it as the first path
> of investigation.
Sorry for in incovinience. I missed the test case. Here it is:
struct s
{
char c[20];
};
void my_func(struct s obj);
void main()
{
int i;
struct s sobj[2];
for (i = 0; i < 2; i++)
my_func(sobj[i]);
}
I dont have any pointer operations. What I observe is that, in sched1, the
instructions are getting scheduled correctly:
;; 2--> 19 r68=[ar6-0x28] ==> Writes to r68
;; 3--> 72 r66=ar7
;; 4--> 22 r69=[ar6-0x24]
;; 5--> 18 [r66++]=r67
;; 6--> 25 r70=[ar6-0x20]
;; 7--> 21 [r66++]=r68 ==> Reads from 68
As we see above, the instructions 19 and 21 are correctly scheduled apart in
sched1, to prevent stalls.
But I see that instruction 19 gets a new number in lreg dump, and gets
placed just before the 21 instruction:
(insn 18 82 81 2 (set (mem:SI (post_inc:PSI (reg/f:PSI 66)) [0 S4 A32])
(reg:SI 67 [ sobj ])) 10 {*movsi} (nil)
(expr_list:REG_DEAD (reg:SI 67 [ sobj ])
(expr_list:REG_INC (reg/f:PSI 66)
(nil))))
(insn 81 18 21 2 (set (reg:SI 68 [ sobj+4 ])
(mem/s:SI (plus:PSI (reg/f:PSI 22 ar6)
(const_int -40 [0xffffffd8])) [4 sobj+4 S4 A32])) 10
{*movsi} (nil)
(expr_list:REG_EQUIV (mem/s:SI (plus:PSI (reg/f:PSI 22 ar6)
(const_int -40 [0xffffffd8])) [4 sobj+4 S4 A32])
(nil)))
(insn 21 81 80 2 (set (mem:SI (post_inc:PSI (reg/f:PSI 66)) [0 S4 A32])
(reg:SI 68 [ sobj+4 ])) 10 {*movsi} (nil)
(expr_list:REG_DEAD (reg:SI 68 [ sobj+4 ])
(expr_list:REG_INC (reg/f:PSI 66)
As we see above, instruction 81 is the same as instruction 19 (of sched1),
and has got placed just above instruction 21, causing a stall.
I am not clear why this happened in lreg? I suspected that it could a part
of some reg-move transformation in register allocation. So, tried option
-fnoreg-move also, but it has no effect.
What should I do now?
--
View this message in context: http://gcc.1065356.n5.nabble.com/Unable-to-remove-stall-at-shed2-tp858757p859010.html
Sent from the gcc - Help mailing list archive at Nabble.com.
