JDK-8312547 : Max/Min nodes Value implementation could be improved
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2023-07-23
  • Updated: 2025-02-20
  • Resolved: 2023-08-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 22
22 b13Fixed
Related Reports
Relates :  
JDK-8350329 - C2: Div looses dependency on condition that guarantees divisor not zero in counted loop after peeling
Description
Max/Min nodes Value implementations inherit from that of AddNode, which checks if either input has type bottom, in which case it returns the local bottom immediately. This is clearly wrong, as Type(Min(x, -1)) should equal to [min_jint, -1] instead of bottom.
Comments
Changeset: 837cf85f Author: Quan Anh Mai <qamai@openjdk.org> Date: 2023-08-25 17:48:27 +0000 URL: https://git.openjdk.org/jdk/commit/837cf85f7d5917f03c61c9bb4b8efe021de92b77
25-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15021 Date: 2023-07-25 15:02:00 +0000
25-07-2023
Good catch! I changed the title from ".. is wrong" to ".. could be improved" because I think the current implementation is just overly conservative here.
24-07-2023
I'm not sure what it means for an input of an AddNode to have the type being Type::BOTTOM, I see that in some nodes we check for this value while for the others there is no such check, anyway it is clearly wrong to check for the local bottom (e.g. TypeInt::INT for MinINode).
24-07-2023