JDK-8259609 : C2: optimize long range checks in long counted loops
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-01-12
  • Updated: 2024-03-27
  • Resolved: 2021-10-26
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 18
18 b21Fixed
Related Reports
Relates :  
JDK-8280600 - C2: assert(!had_error) failed: bad dominance
Relates :  
JDK-8223051 - support loops with long (64b) trip counts
Relates :  
JDK-8276116 - C2: optimize long range checks in int counted loops
Relates :  
JDK-8278296 - Generalize long range check transformation
Relates :  
JDK-8314580 - PhaseIdealLoop::transform_long_range_checks fails with assert "was tested before"
Relates :  
JDK-8329163 - C2: possible overflow in PhaseIdealLoop::extract_long_range_checks()
Relates :  
JDK-8278790 - Inner loop of long loop nest runs for too few iterations
Description
JDK-8255150 makes it possible for java code to explicitly perform a range check on long values. JDK-8223051 provides a transformation of long counted loops into loop nests with an inner int counted loop. With this change I propose transforming long range checks that operate on the iv of a long counted loop into range checks that operate on the iv of the int inner loop once it has been created. Existing range check eliminations can then kick in.
Comments
Good catch, [~xliu]. That should be fixed. Could you please file a bug?
24-11-2022
hi, @roland, I notice that you introduce a new class type LSHIFT here. https://github.com/openjdk/jdk/pull/2045/files#diff-17a9d48a5570e5bcde557c8d1efcbe78d69a5657bc865bed37b22c3c8b5d447d but you didn't reset _max_classes of the enum NodeClasses. Is it an overlook or intentional? I look up _max_classes. it is not used in any real code but just a sanity check. even though it's very unlikely to hit the overflow, we better off fixing it beforehand. what do you think? ./share/opto/node.cpp:1084: assert(_max_classes <= max_juint, "too many NodeProperty classes");
23-11-2022
Changeset: 82f4aacb Author: Roland Westrelin <roland@openjdk.org> Date: 2021-10-26 15:53:37 +0000 URL: https://git.openjdk.java.net/jdk/commit/82f4aacb42e60e9cd00e199703a869e7ad4465ff
26-10-2021