The common OMR::CodeGenerator has a function isRotateAndMask that is asked on behalf of a TR::Node. This is a Power architecture question and pattern match only, and really should be a asked on the TR::Node itself.
Hence, relocate this function to the OMR::Node class and provide the Power-specific override in a p/il/OMRNode.[ch]pp class.
The description of this issue has changed in case anyone was actively considering it.
Should I create the OMRNode.cpp and OMRNode.hpp in p/il/ . And is there any other function to be added to them except isRotateAndMask
Seems like a question the optimizer might also have an interest in asking, even if it hasn't to date.
Do we really want to specialize Node just for this one function? Are there other functions that also motivate architecture specific Node extensions?
The reason I ask is that specialization in one place (especially a place like Node) tends to force specialization in other places where it may be harder to implement the specialization (like a sequence of pattern matchings in the optimizer).
What are your thoughts @vijaysun @andrewcraik ?
Profuse apologies for not asking this question earlier; I know we now have an open pull request for it...
I am not a fan of codegen specific IL / nodes - the current compiler is complex enough without having to wonder what kind of node you have. The IL is common currency of the optimizer and the codegens and avoiding fragmentation is key to keeping things shareable and understandable. The query is not a property of a single node but is asking a question about a pattern of nodes and for that reason I don't think it should be on node. If we don't want it in the code generator or we want to try and corral pattern matchers then I would suggest we have a matcher utility class and put it in there. That class should not be Power specific - this concept can apply on other codegens and could apply in the optimizer.
Most helpful comment
I am not a fan of codegen specific IL / nodes - the current compiler is complex enough without having to wonder what kind of node you have. The IL is common currency of the optimizer and the codegens and avoiding fragmentation is key to keeping things shareable and understandable. The query is not a property of a single node but is asking a question about a pattern of nodes and for that reason I don't think it should be on node. If we don't want it in the code generator or we want to try and corral pattern matchers then I would suggest we have a matcher utility class and put it in there. That class should not be Power specific - this concept can apply on other codegens and could apply in the optimizer.