Support IEEE-754 for fmin/fmax/dmin/dmax nodes - #7464
Conversation
88e0beb to
65d97f3
Compare
0c276e5 to
9670bf9
Compare
2f62f58 to
15a2d2b
Compare
db6022b to
ccc837d
Compare
|
can you review please @r30shah ? |
ccc837d to
9ec2ebd
Compare
|
|
||
| TR::Register* lhsReg = cg->gprClobberEvaluate(lhsNode); | ||
| TR::Register* rhsReg = cg->evaluate(rhsNode); | ||
| TR::Node * lhsNode = node->getChild(0); |
There was a problem hiding this comment.
Can we rename lhsNode and rhsNode ?
| bool isFloatingPointOp = node->getOpCode().isFloatingPoint(); | ||
| if (isFloatingPointOp) | ||
| { | ||
| compareRROp = node->getOpCode().isDouble() ? TR::InstOpCode::CDBR : TR::InstOpCode::CEBR; |
There was a problem hiding this comment.
Seems like you have extra indentation here in the next else block
| } | ||
|
|
||
| TR::LabelSymbol* cFlowRegionEnd = generateLabelSymbol(cg); | ||
| TR::LabelSymbol* swap = generateLabelSymbol(cg); |
There was a problem hiding this comment.
I may have missed this in initial review, but swapValue or something meaningful name should be used.
| if (isFloatingPointOp) | ||
| { | ||
| /* | ||
| Check for NaN operands for float and double |
There was a problem hiding this comment.
Can you use doxygen styled block comment (like done in [1] for example)
| static TR::Register *MethodEnterHookEvaluator(TR::Node *node, TR::CodeGenerator *cg); | ||
| static TR::Register *MethodExitHookEvaluator(TR::Node *node, TR::CodeGenerator *cg); | ||
| static TR::Register *PassThroughEvaluator(TR::Node *node, TR::CodeGenerator *cg); | ||
| static TR::Register *fpMinMaxVectorHelper(TR::Node *node, TR::CodeGenerator *cg); |
There was a problem hiding this comment.
Either here or where the function is implemented, we should add a doxygen styled comments for function description(Take a look at functions in z/OMRTreeEvaluator.hpp [1])
| { | ||
| result = OMR::Z::TreeEvaluator::xmaxxminhelper(node, cg); | ||
| } | ||
| generateRREInstruction(cg, TR::InstOpCode::LTDBR, node, result, result); |
There was a problem hiding this comment.
We should add a brief explanation for these Load Test instructions.
| static TR::Register* | ||
| xmaxxminHelper(TR::Node* node, TR::CodeGenerator* cg, TR::InstOpCode::Mnemonic compareRROp, TR::InstOpCode::S390BranchCondition branchCond, TR::InstOpCode::Mnemonic moveRROp) | ||
| TR::Register * | ||
| OMR::Z::TreeEvaluator::xmaxxminhelper(TR::Node * node, TR::CodeGenerator * cg) |
There was a problem hiding this comment.
I think the original name xmaxminHelper should be ok (You missed the caps in Helper when refactoring).
9ec2ebd to
4c079e5
Compare
4c079e5 to
d1af547
Compare
| /* Check for NaN operands for float and double | ||
| * Support float and double +0/-0 comparisons adhering to IEEE 754 standard | ||
| * Checking if operands are equal, then branching to equalRegion, otherwise | ||
| * fall through for NaN case handling | ||
| */ |
There was a problem hiding this comment.
| /* Check for NaN operands for float and double | |
| * Support float and double +0/-0 comparisons adhering to IEEE 754 standard | |
| * Checking if operands are equal, then branching to equalRegion, otherwise | |
| * fall through for NaN case handling | |
| */ | |
| /** | |
| * Check for NaN operands for float and double | |
| * Support float and double +0/-0 comparisons adhering to IEEE 754 standard | |
| * Checking if operands are equal, then branching to equalRegion, otherwise | |
| * fall through for NaN case handling | |
| */ |
| TR::Register * | ||
| OMR::Z::TreeEvaluator::fpMinMaxVectorHelper(TR::Node *node, TR::CodeGenerator *cg) | ||
| { | ||
| TR_ASSERT(node->getNumChildren() >= 1 || node->getNumChildren() <= 2, "node has incorrect number of children"); |
There was a problem hiding this comment.
We should combine this two asserts.
|
|
||
| /** \brief | ||
| * This is a helper function used for floating point max/min operations | ||
| * when SIMD instructions are available. +0.0 compares as strictly |
There was a problem hiding this comment.
I think we should mention that it generates Vector Instructions when available for max/min operations.
Looking at your openJ9 change, is this statement true? Without OpenJ9 change , Java should not be inlining max and min for floating point types right >? |
ah yes, they won't be inlined without the openj9 change. But the openj9 PR won't compile without this PR, so this one still needs to be merged first. |
|
@hzongaro can you review when you get the chance? |
3511fe1 to
cc9736b
Compare
Add Math.max/min/F/D to list of recognized Java methods to: - Disable special aliasing rules since they are intrinsically optimized - Disable implicit asynchronous checks Signed-off-by: Sarwat Shaheen <sarwat.shaheen@yahoo.com>
cc9736b to
f82bf4a
Compare
hzongaro
left a comment
There was a problem hiding this comment.
I think the changes look good overall. Just a few minor comments.
May I also ask you to update the commit comments to indicate that these changes are for inline code for z/Architecture only?
f82bf4a to
c925738
Compare
581db9b to
d54e28e
Compare
9bd6113 to
d3aff89
Compare
hzongaro
left a comment
There was a problem hiding this comment.
Looks good. Just one further minor comment.
d3aff89 to
da17b3f
Compare
- changes are only for the floating point min/max evaluators on z/Architecture - +0.0 compares as strictly greater than -0.0 - Refactored xmaxxminHelper to into a more generic helper function that does not change NaNs - added helper for fmin/fmax/... nodes that uses SIMD instructions when available that has same behaviour as xmaxxminHelper on floats - idea is to enable other evaluators to use these helpers and deal with NaNs as they see fit - omr evaluators support IEEE-754 w.r.t zeros and NaNs (returns the quiet NaN corresponding to the first NaN given if present) Signed-off-by: Matthew Hall <matthew.hall3@outlook.com>
da17b3f to
fefb344
Compare
r30shah
left a comment
There was a problem hiding this comment.
Thanks @matthewhall2 for the changes, it looks good to me, will wait for @hzongaro to approve and merge this before I go on and look at the J9 changes.
|
jenkins build zos,zlinux |
hzongaro
left a comment
There was a problem hiding this comment.
Looks good. Thanks for addressing the comments!
xmaxxminhelperto infer correct compare/branch/move instructions based on datatype; helper does not change NaNs, so can be used in other min/max evaluators which can extend the behaviour on NaNs as they see fitDepends on OMR Simplifier change #7471 (needed for eclipse-openj9/openj9#20185 to pass)
https://hyc-runtimes-jenkins.swg-devops.com/job/jvm.29.personal/34283/