This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unable to remove stall at shed2


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]