Omr: Adding floating point constraints to the Value Propagation optimization

[wbh123456]

Currently we do not constrain floating points in Value Propagation like we do for integer types. Need to add features such as VPFloatConstraint, VPFloatConst, VPFloatRange, VPDoubleConstraint, VPDoubleConst, VPDoubleRange, etc.

[wbh123456]

@vijaysun-omr @andrewcraik . Since we are adding new classes to the VPConstraints, we need to extend the MergePriorities field as well. What should the the priority of the float/double constraints be? In addition, does float/double constraints intersect/merge with other types (e.g. long, short, int types)?

[andrewcraik]

so a given stack slot should not be both a float and an int at the same time. Further for an int to be combined with a float would require an explicit conversion in the trees. As a result I don't think you have to worry about the merge of float/double with long/int - a simple don't know should be good enough to start with. Some care will be needed in comparing float/double ranges and constants since floating point equality is tricky. The priority is determined by where the handling logic is and will need some careful consideration.

[wbh123456]

@vijaysun-omr @andrewcraik The float constraint is almost complete but I still have several questions:

1. When we try to add/sub two floating point constraints, what should the numeric result be if the result overflow? Should we define the summation to be either INF or -INF when overflowed or leave it as what the computational result is for a + b, even though it might turn into undefined behavior? Also note that the current behavior for int/short/long overflow is sum = a + b - range as it casts the operand to unsigned type before doing the addition. https://github.com/eclipse/omr/blob/c56c5c432457f865dee99b22495080d5339dc7ef/compiler/optimizer/VPConstraint.hpp#L284
2. How should we test functionality correctness of the floating point constraints classes, e.g. VPFloatConstraint, VPFloatConst, VPFloatRange.

[andrewcraik]

@wbh123456 we should not be relying on compiler undefined behavior in any situation. As for the value to be produced, if we can't figure out a reasonable 'right' answer then we should just not have a constraint on the result of the addition - the safest thing.

[wbh123456]

@wbh123456 we should not be relying on compiler undefined behavior in any situation. As for the value to be produced, if we can't figure out a reasonable 'right' answer then we should just not have a constraint on the result of the addition - the safest thing.

Thank you for your reply. I agree with you that the safest way is to have no constraint on overflow. Just to be very specific, may I clarify our solution with a particular example:
- Assume we have two range constraints: A = [-3, 6], B = [-1, 8] and the full range for this type is [-10, 9]. If we try to add these two constraints, we encounter an overflow on the higher bound of the range because 6 + 8 > 9. As for what the current implementation for int/long/short constraint is, the computational result of (6 + 8) = 14 - 20 = -6. Therefore A + B would result into a merged constraint of {[-10, -6], [-4, 14]}. However, if this is for floating point constraint, does A + B just return NULL here?

[wbh123456]

@wbh123456 we should not be relying on compiler undefined behavior in any situation. As for the value to be produced, if we can't figure out a reasonable 'right' answer then we should just not have a constraint on the result of the addition - the safest thing.

Thank you for your reply. I agree with you that the safest way is to have no constraint on overflow. Just to be very specific, may I clarify our solution with a particular example:

• Assume we have two range constraints: A = [-3, 6], B = [-1, 8] and the full range for this type is [-10, 9]. If we try to add these two constraints, we encounter an overflow on the higher bound of the range because 6 + 8 > 9. As for what the current implementation for int/long/short constraint is, the computational result of (6 + 8) = 14 - 20 = -6. Therefore A + B would result into a merged constraint of {[-10, -6], [-4, 14]}. However, if this is for floating point constraint, does A + B just return NULL here?

@andrewcraik @vijaysun-omr Ping

[andrewcraik]

If we cannot accurately represent the result then we should not produce a result. If we cannot agree on the right representation for overflow the safest thing to do is to produce no constraint on merge and we can refine it later.

[vijaysun-omr]

Yes that was my view as well, that we should not get bogged down in edge cases to start with.