[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 #26 from Saam Barati <sbarati at apple.com> ---
Comment on attachment 291111
  --> https://bugs.webkit.org/attachment.cgi?id=291111
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?

-- 
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/20161012/69ec30e5/attachment.html>