[Webkit-unassigned] [Bug 99213] [ARMv7] LinkBuffer flushes code unnecessarily for every link

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=99213





--- Comment #9 from Yong Li <yoli at rim.com>  2012-10-16 07:40:28 PST ---
(In reply to comment #8)
> > > Why make this optimization CPU-specific?
> > 
> > This is only an issue in ARMv7Assembler. Other assemblers don't have this problem. x86/x64 don't need to flush code. ARM-traditional/mips/sh4 don't flush code in linkCall()
> 
> It seems brittle, and a layering violation, for the ARMv7 assembler to guess that calls like linkCall() and linkPointer() will always be followed by a call to cacheFlush().
> 
> Even though you believe, based on reading the implementation details of all our assemblers, that only ARMv7 needs this particular optimization at this time, and that the optimization is correct for the current implementation of LinkBuffer, the goal of our MacroAssembler and LinkBuffer interfaces is to abstract away those details so we can make future changes without thinking about all platforms at once.
> 
> Is there a major blocker that forces this code to be ARMv7-specific?

Maybe the title is confusing. I thought It was a more generic issue at the very beginning. However after reading more code, I found that it is not LinkBuffer's fault at all. I believe that none of the link*() calls need/should flush code. LinkBuffer will flush the entire assembly at the finalization step. However, those relink*/repatch*/replace* calls must flush code (except for x86 families). None of other assemblers flush code in linkCall() and linkPointer(), and ARMv7Assembler doesn't flush in linkJump(). So I think we can call it a bug in ARMv7Assembler, and it is an accident that linkCall/linkPointer finally flushes code through setInt32.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.