[PATCH] Fix mips_expand_synci_loop

David Daney ddaney@caviumnetworks.com
Tue Oct 6 19:21:00 GMT 2009


Fu, Chao-Ying wrote:
> David Daney wrote:
>>> gcc/ChangeLog
>>> 2009-10-05  Chao-ying Fu  <fu@mips.com>
>>>
>>> 	* config/mips/mips.c (mips_expand_synci_loop): 
>> Increment the "begin" rtx,
>>> 	then check the "begin" rtx against the "end" rtx.
>>>
>> I cannot approve the patch, but it seems plausible.
>>
>> Can you tell us how it was tested?
>>
> 
>   Actually, I just built the whole GCC mainline again.
> 
>   This bug was detected on Debian on a 24kf Malta board, when I was
> doing a JIT application that needs to flush cache for some generated MIPS code.
> 
>   I found that my patch may skip the last synci for the end address (-1).
> Maybe we need to append an extra synci at the end.
> 

This is kind of ugly, but will probably work.

Would it be more elegant to mask the base address with ~(hwr_synci_step 
- 1) before entering the loop?

But this raises an even bigger question in my mind:  Which version of 
GCC are you patching?  The trunk should not be generating this code at 
all for linux targets (like Debian).  It must expand to a syscall 
instead of in-line SYNCIs.

David Daney

> Ex: (New code)
>    46c724:       rdhwr   v1,hwr_synci_step
>    46c728:       synci   0(a1)
>    46c72c:       addu    a1,a1,v1
>    46c730:       sltu    v0,a2,a1
>    46c734:       beqz    v0,46c728
>    46c738:       nop
>    46c73c:       addiu   a2,a2,-1
>    46c740:       synci   0(a2)
> 
>   I am still thinking about how to improve this sequence.  If anyone has a better idea,
> please let me know.  Thanks!
> 
> Regards,
> Chao-ying
> 



More information about the Gcc-patches mailing list