[Webkit-unassigned] [Bug 160588] Refactor MathIC compilation process in Baseline and DFG to turn temporary registers usage more flexible

[bugzilla-daemon at webkit.org]

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

--- Comment #27 from Caio Lima <ticaiolima at gmail.com> ---
(In reply to comment #26)
> Comment on attachment 291111 [details]
> Patch
> 
> Something about this patch doesn't sit right with me, and I think I've
> finally figured out what it is.
> This API doesn't seem scalable to adding more math ICs that need more
> scratch registers. I think we need
> to move to a more dynamic API, by either passing in a vector of scratch
> registers, or a RegisterSet of used registers.
> The reason this code feels so weird to me is that you've started to make
> this API more dynamic, yet you're still calling
> the exact same constructors. So it's only pretending to be more dynamic, but
> in reality, it's not.
> Also, the code is just much harder to follow now. 
> I'm not sure what the best API is. Here are two options:
> 1. If we pass in a RegisterSet of used registers, each snippet will now be
> responsible for allocating scratch
> registers using the scratch register allocator.
> 2. Alternatively, we can keep most of your patch like it is now, but pass in
> a vector of scratch registers.
> Each snippet constructor can deconstruct the vector into member variables
> and assert that none are InvalidGPR/FPRReg.
> The vector can have an inlinecapacity of
> scratchGPRRegCount/scratchFPRRegCount and just be the vector of registers.
> 
> I think I prefer 2. Maybe you have other ideas?

I remember discussing with you a long time ago that I proposed to you use a vector, however you gave me an answer that convinced me. The problem is that the vector is going to inflate all ICs, mainly the ones that use just 1 scratch.

If I understood your idea, we could use GPRReg allocatedRegs[scratchGPRRegCount] and pass it to JIT*Generator and the Generator just validate if they are invalid or not. This implementation is going to use sizeof(GPRReg * scratchGPRRegCount) memory, which means sizeof(GPRReg) if scratchGPRRegCount = 1. Is it right? If yes, I can't think in a better solution right now and the idea of Generators being responsible to allocate its scratches doesn't sound right IMO.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161022/6c24b2d0/attachment-0001.html>