Currently some nodes have a mutable set of arithmetic use flags, and all nodes have a mostly-immutable set of flags baked into their opcode. Instead, the opcode should be a 16-bit quantity that does not include any flags, and separately, there should be a 16-bit flags that combines the current flags-that-are-in-the-opcode and the arithmetic flags. This will facilitate richer backward flow analyses and should make manipulating the DFG IR generally easier.
<rdar://problem/11026218>
Created attachment 131205 [details] the patch
Attachment 131205 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/CMakeLists.txt', u'S..." exit_code: 1 Source/JavaScriptCore/dfg/DFGNode.h:114: The parameter name "flags" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 1 in 17 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 131205 [details] the patch Attachment 131205 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/11936304
Comment on attachment 131205 [details] the patch Attachment 131205 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/11939311
Created attachment 131206 [details] the patch Ooops, forgot about 32_64. This patch fixes that.
Created attachment 131273 [details] the patch Just rebased it.
There is an awful lot of static_cast<NodeType>(node.op) in this patch. It would be really good to make op private (& probably should be called m_op), and change op() to be an accessor function returning a NodeType. Would probably be nice to do the same for flags. What do you think?
(In reply to comment #8) > There is an awful lot of static_cast<NodeType>(node.op) in this patch. It would be really good to make op private (& probably should be called m_op), and change op() to be an accessor function returning a NodeType. Would probably be nice to do the same for flags. What do you think? I'm with you! I had avoided doing that because I had already racked up 50kb of changes. I feared that privatizing Node::op will introduce even more changes. I want to make that change and would be happy to do it in this patch. But how would you feel about that being a follow-on patch?
> I want to make that change and would be happy to do it in this patch. But how would you feel about that being a follow-on patch? That works for me.
Landed in http://trac.webkit.org/changeset/110419