[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