8360192: C2: Make the type of count leading/trailing zero nodes more precise #25928

MaxXSoft · 2025-06-23T03:31:36Z

The result of count leading/trailing zeros is always non-negative, and the maximum value is integer type's size in bits. In previous versions, when C2 can not know the operand value of a CLZ/CTZ node at compile time, it will generate a full-width integer type for its result. This can significantly affect the efficiency of code in some cases.

This patch makes the type of CLZ/CTZ nodes more precise, to make C2 generate better code. For example, the following implementation runs ~115% faster on x86-64 with this patch:

public static int numberOfNibbles(int i) {
  int mag = Integer.SIZE - Integer.numberOfLeadingZeros(i);
  return Math.max((mag + 3) / 4, 1);
}

Testing: tier1, IR test

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8360192: C2: Make the type of count leading/trailing zero nodes more precise (Enhancement - P4)

Reviewers

Quan Anh Mai (@merykitty - Committer)
Jatin Bhateja (@jatin-bhateja - Reviewer) Review applies to b4b9b643
Emanuel Peter (@eme64 - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25928/head:pull/25928
$ git checkout pull/25928

Update a local copy of the PR:
$ git checkout pull/25928
$ git pull https://git.openjdk.org/jdk.git pull/25928/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25928

View PR using the GUI difftool:
$ git pr show -t 25928

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25928.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-06-23T03:32:22Z

👋 Welcome back qxing! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-06-23T03:32:25Z

@MaxXSoft This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8360192: C2: Make the type of count leading/trailing zero nodes more precise

Reviewed-by: qamai, epeter, jbhateja

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 333 new commits pushed to the master branch:

a840dc2: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly
a98b9e7: 8362832: compiler/macronodes/TestTopInMacroElimination.java hits assert(false) failed: unexpected node
19cca0a: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods
... and 330 more: https://git.openjdk.org/jdk/compare/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@jaskarth, @merykitty, @jatin-bhateja, @eme64) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk · 2025-06-23T03:33:01Z

@MaxXSoft The following label will be automatically applied to this pull request:

hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-06-23T03:36:12Z

Webrevs

merykitty · 2025-06-23T06:00:37Z

A stricter bound would be TypeInt::make(~t._bits._zeros, t._bits._ones, t._widen)

MaxXSoft · 2025-06-23T06:20:11Z

A stricter bound would be TypeInt::make(~t._bits._zeros, t._bits._ones, t._widen)

@merykitty Thanks for your review, did you mean TypeInt::make(clz(~t._bits._zeros), clz(t._bits._ones), t._widen)?

merykitty · 2025-06-23T07:41:01Z

@MaxXSoft Yes you are right, my mistake

eme64 · 2025-06-23T10:38:37Z

src/hotspot/share/opto/countbitsnode.cpp

+#include "utilities/count_leading_zeros.hpp"
+#include "utilities/count_trailing_zeros.hpp"
+
+static int count_leading_zeros_int(jint i) {
+  return i == 0 ? BitsPerInt : count_leading_zeros(i);
+}
+
+static int count_leading_zeros_long(jlong l) {
+  return l == 0 ? BitsPerLong : count_leading_zeros(l);
+}
+
+static int count_trailing_zeros_int(jint i) {
+  return i == 0 ? BitsPerInt : count_trailing_zeros(i);
+}
+
+static int count_trailing_zeros_long(jlong l) {
+  return l == 0 ? BitsPerLong : count_trailing_zeros(l);
+}


Can you explain why you need this?
Why is count_trailing_zeros and count_leading_zeros not enough, when you cast at the use-site?

This is because our implementation does not accept 0 as an input. I suggest doing this at count_leading_zeros, it makes more sense and also aligns our behaviour with the well-known countr_zero and countl_zero

Can you explain why you need this? Why is count_trailing_zeros and count_leading_zeros not enough, when you cast at the use-site?

@eme64 The explanation of @merykitty is right, the implementation of count_leading_zeros and count_trailing_zeros reject zero as the input.

Perhaps we could open another PR to add zero support for these functions, since it's less relevant to this node type change and might require other changes to the code that calls them.

In src/hotspot/share/utilities/count_leading_zeros.hpp, it says that 0 behavior is undefined. Ok... but why do we do that? Is that a performance optimization ? If yes, is it really worth it? If there is no good reason not to handle 0, we should just handle it.

We have some tests in test/hotspot/gtest/utilities/test_count_leading_zeros.cpp.

It would be interesting to quickly check if any use of these methods could ever encounter zero, and then hit the assert. I would not be surprised if we found a bug here.

I think this would be a worth while cleanup task. I would prefer if we clean things up now, and don't just let more special handling code get integrated.

src/hotspot/share/opto/countbitsnode.cpp

test/hotspot/jtreg/compiler/c2/irTests/TestCountBitsRange.java

liach · 2025-06-23T23:07:29Z

test/hotspot/jtreg/compiler/c2/irTests/TestCountBitsRange.java

+    @Test
+    @IR(failOn = IRNode.COUNT_LEADING_ZEROS_I)
+    public boolean clzCompareInt() {
+        return Integer.numberOfLeadingZeros(i) < 0 || Integer.numberOfLeadingZeros(i) > 32;


You limited the type to check the ones/zeroes of the input value, count_leading_zeros_int(~ti->_bits._zeros), count_leading_zeros_int(ti->_bits._ones),. I think we need test cases to cover those too, given they are more complex and thus more error prone.

I have no idea how the KnownBits works. I tried masking i with i & 0x00ffffff | 0x0000ffff, and evaluating CLZ on it. But C2 still seems to return an integer type with a trivial KnownBits, instead of KnownBits with _zeros=0xff000000 and _ones=0x0000ffff.

I also checked the PR which introduced KnownBits (#17508). @merykitty said "there is no node taking advantage of the additional information yet", and there's no IR tests in that PR. So it's probably impossible to write a test for this at the moment?

@merykitty Could you provide more help on this please? Thanks.

src/hotspot/share/opto/countbitsnode.cpp

bridgekeeper · 2025-07-22T18:08:52Z

@MaxXSoft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

MaxXSoft · 2025-07-24T02:10:01Z

Hi all,

This patch has now passed all GHA tests and is ready for further reviews.

If there are any other suggestions for this PR, please let me know.

Thanks!

jaskarth

This is nice! I just have a comment on the unit test.

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

jatin-bhateja · 2025-08-06T10:42:42Z

src/hotspot/share/opto/countbitsnode.cpp

+  const TypeLong* tl = t->is_long();
+  if (tl->is_con()) {
+    return TypeInt::make(count_leading_zeros_long(tl->get_con()));
+  }
+  return TypeInt::make(count_leading_zeros_long(~tl->_bits._zeros),
+                       count_leading_zeros_long(tl->_bits._ones),
+                       tl->_widen);


Hi @MaxXSoft, Taking the liberty to add some comments related to the proof of the above assumptions, hope you won't mind :-)

Z3 proof for [KnownBits.ONES, ~KnownBits.ZEROS] >= [LB, UB] where >= is a superset relation.

from z3 import * from functools import reduce # 64-bit symbolic unsigned integers UB = BitVec('UB', 64) LB = BitVec('LB', 64) # XOR for detecting differing bits xor_val = UB ^ LB # COUNT_LEADING_ZEROS def count_leading_zeros(x): """Returns number of leading zeros in a 64-bit word.""" clauses = [] for i in range(64): bit_is_one = LShR(x, 63 - i) & 1 == 1 bits_before_zero = And([LShR(x, 63 - j) & 1 == 0 for j in range(i)]) clauses.append(If(And(bits_before_zero, bit_is_one), BitVecVal(i, 64), BitVecVal(64, 64))) return reduce(lambda a, b: If(a == 64, b, a), clauses) # Step 1: Compute common prefix length CPL = count_leading_zeros(xor_val) # Step 2: COMMON_PREFIX_MASK = ((1 << CPL) - 1) << (64 - CPL) one_shifted = (BitVecVal(1, 64) << CPL) mask = one_shifted - 1 COMMON_PREFIX_MASK = mask << (64 - CPL) # Step 3: COMMON_PREFIX COMMON_PREFIX = UB & COMMON_PREFIX_MASK # Step 4: ZEROS and ONES ZEROS = COMMON_PREFIX_MASK & (~COMMON_PREFIX) ONES = COMMON_PREFIX # Step 5: Prove that [ONES, ~ZEROS] ⊇ [LB, UB] prop = And(ULE(ONES, LB), ULE(UB, ~ZEROS)) # Step 6: Try to disprove (i.e., check if any UB, LB violates the above) s = Solver() s.add(Not(prop)) # Look for counterexamples # Check the result if s.check() == sat: m = s.model() ub_val = m.eval(UB).as_long() lb_val = m.eval(LB).as_long() ones_val = m.eval(ONES).as_long() zeros_val = m.eval(ZEROS).as_long() not_zeros_val = (~zeros_val) & 0xFFFFFFFFFFFFFFFF print("❌ Property does NOT hold. Counterexample found:") print(f"LB = {lb_val:#018x}") print(f"UB = {ub_val:#018x}") print(f"ONES = {ones_val:#018x}") print(f"~ZEROS = {not_zeros_val:#018x}") print(f"ONES <= LB? {ones_val <= lb_val}") print(f"UB <= ~ZEROS? {ub_val <= not_zeros_val}") else: print("✅ Property holds: [ONES, ~ZEROS] always covers [LB, UB] (UNSAT)")

Manually worked out Example 1:-
UB = 0xFFFF00FF
LB = 0xFFFF0000
COMMON_PREFIX = 0xFFFF0000
ONES = 0xFFFF0000
ZEROS = 0x00000000
---------------------------
MAX = ~ZEROS
= 0xFFFFFFFF
MIN = ONES
= 0xFFFF0000

Thus, it's evident that MAX >= UB AND MIN <= LB

Manually worked out Example 2:-
UB = 0xFF0F00FF
LB = 0xFF0F0000
COMMON_PREFIX = 0xFF0F0000
ONES = 0xFF0F0000
ZEROS = 0x00F00000

Since logical OR b/w ONES and ZEROS forms the COMMON_PREFIX MASK i.e. both ZEROS and ONES are derived from COMMON_PREFIX therefore COMMON_PREFIX_MASK & ~ZERO == COMMON_PREFIX_MASK & ONES, apart from COMMON_PREFIX there are other lower order bits which are not included in COMMON_PREFIX, when we flip the ZEROS then we get a VALUE which equals ONES + we set all other lower order bits, thus this value is guaranteed to be greater than UB since it also set other non-set bits of UB.

Thus, UB = COMMON_PREFIX + OTHER_SET_LOWER_ORDER_BITS_IN_UB
~ZEROS = COMMON_PREGIX + REMAINING_BITS_SET_TO_ONE.

While ONES is just the common prefix, which is guaranteed to be less than UB since we don’t account for set bits of UB, which are not part of the common prefix.

Thus, the following inequality holds good.

~ZEROS >= UB >= LB >= ONES

Proof for the KnownBits application to CTZ / CLZ

In both these cases, we are only concerned about the number of ZEROs which are either present at the start or towards the end of the integral bits sequence.

KnownBits.ZEROS and KnownBits.ONES captures the known set bits in value range, i.e., if a bit is set on ONES it means it's guaranteed to be one in all the values in the value range; similarly, a set bit in ZEROS signifies that the corresponding bit remains unset in all the values in the range. All unset bits in ONES/ZEROS signify not known at compile time.

Since the flipped value of ZEROS gives us the maximum value in the range, and given that number of leading zeros of maximum value will never be greater than the number of leading zeros of minimum value of the range hence, value range of CLZ varies b/w CLZ(~ZEROS) and CLZ(ONES) as its lower and upper bounds.

While counting leading zeros is relatively straightforward to prove given that each integral value is the sum of 2^position of set bits and given that TypeInt/TypeLong comply with the invariant (LB <= UB)
Hence highest set bits position of UB can never be less than the LB.

For CTZ, consider the following example
UB = 0xFF800000
LB = 0xFF8FF0F0
COMMON_PREFIX = 0xFF800000
ONES = 0xFF800000
ZEROS = 0x00700000

Again, both ONES and ZEROS bits are extracted from the common prefix of the delimiting bounds of the value range.

MAX = ~ZEROS = 0xFF8FFFFF
MIN = ONES = 0xFF800000

Thus, the number of trailing zeros will be [lb:0, ub:20], given that the lower order bits of knowbits which are not part of the common prefix will always be set to zero, hence CTZ(~ZERO) will always be 0. This is also in line with the fact that the number of leading/trailing zeros will never be a non-negative value. Therefore, delimiting lower and upper bounds of CTZ are CTZ(~ZEROS) and CTZ(ONES).

Thanks for the addition! Very nice and solid proof.

Hi @MaxXSoft, Constant folding optimizations like these qualify for addition of a new benchmark. Please add one; I see a significant gain with following micro kernel on my Intel 13th Gen Intel(R) Core(TM) i3-1315U laptop.

public static long micro(long param) { long constrained_param = Math.min(175, Math.max(param, 160)); return Long.numberOfLeadingZeros(constrained_param); } PROMPT>#baseline PROMPT>java -Xbatch -XX:-TieredCompilation -cp . test_clz [time] 17ms [res] 11200000 PROMPT>#withopt PROMPT>java -Xbatch -XX:-TieredCompilation -cp . test_clz [time] 5ms [res] 11200000

src/hotspot/share/opto/countbitsnode.cpp

eme64

I'll run some testing and review afterward.

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

eme64

Looks like a good patch, thanks for the work and patience with the review - it's been a bit slow over summer with vacation/travel.

eme64 · 2025-08-19T13:43:37Z

src/hotspot/share/opto/countbitsnode.cpp

+#include "utilities/count_leading_zeros.hpp"
+#include "utilities/count_trailing_zeros.hpp"
+
+static int count_leading_zeros_int(jint i) {
+  return i == 0 ? BitsPerInt : count_leading_zeros(i);
+}
+
+static int count_leading_zeros_long(jlong l) {
+  return l == 0 ? BitsPerLong : count_leading_zeros(l);
+}
+
+static int count_trailing_zeros_int(jint i) {
+  return i == 0 ? BitsPerInt : count_trailing_zeros(i);
+}
+
+static int count_trailing_zeros_long(jlong l) {
+  return l == 0 ? BitsPerLong : count_trailing_zeros(l);
+}


In src/hotspot/share/utilities/count_leading_zeros.hpp, it says that 0 behavior is undefined. Ok... but why do we do that? Is that a performance optimization ? If yes, is it really worth it? If there is no good reason not to handle 0, we should just handle it.

We have some tests in test/hotspot/gtest/utilities/test_count_leading_zeros.cpp.

It would be interesting to quickly check if any use of these methods could ever encounter zero, and then hit the assert. I would not be surprised if we found a bug here.

I think this would be a worth while cleanup task. I would prefer if we clean things up now, and don't just let more special handling code get integrated.

eme64 · 2025-08-19T13:50:28Z

src/hotspot/share/opto/countbitsnode.cpp

+  return TypeInt::make(count_leading_zeros_int(~ti->_bits._zeros),
+                       count_leading_zeros_int(ti->_bits._ones),


I think this is correct, but I would like to see a short comment why it is correct.

Same in other cases below

src/hotspot/share/opto/countbitsnode.cpp

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

eme64 · 2025-09-09T08:40:35Z

@MaxXSoft Feel free to just ping me again when you want another review :)
FYI: I'll be on a longer vacation starting in about a week, so don't expect me to respond then.

MaxXSoft · 2025-09-10T07:15:47Z

@eme64 Thank you for your patience and kind reviews! I've updated this patch based on your suggestions.

This patch is now ready for further review.

eme64

Thanks for the update. Though I think you modified the test example so far that it does not work any more, i.e. it would not constant fold if the output range was wrong. I've identified 2 sources that would prevent constant folding:

It is unclear if getResultChecksum would get inlined. That way, the result loses the type information about the ranges.
The comparisons themselves would not constant fold, because the values you compare with are not constants, but array element loads. You need to compare result with a compile time constant.

Maybe the idea is not 100% clear for you:
Imagine result should be in some range 2..10. But with a bug, we now return 3..10. This means the output of numberOfLeadingZeros is still variable, and it does not constant fold. But: if there is something below it, like a result < 3 ... this would now constant fold to false, even though we could have had a 2 at runtime.
But for this to work, it all needs to be in the same compilation unit, and the value we compare to result must be a compile time constant.

Does that make sense?

eme64 · 2025-09-12T12:46:44Z

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

+        }
+    }
+
+    int getResultChecksum(int result, int[] LIMITS) {


I would put a @ForceInlinie before this. You are using it in many methods, and so it may not get inlined reliably. And if it does not get inlined, then the result verifcation would not constant-fold, and so it would be kind of useless. Because we rely on the fact that if the range is wrong, we could get bad constant folding ;)

Added @ForceInline.

eme64 · 2025-09-12T12:47:56Z

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

+        for (int i = 0; i < LIMITS.length; i += 2) {
+            if (result < LIMITS[i]) sum += 1 << i;
+            if (result > LIMITS[i + 1]) sum += 1 << (i + 1);
+        }


I doublt that this works, because the test would not constant fold if the range was too narrow.
I think you need to manually unroll the loop, and load the constants from static final values, or another method that allows it to be a compile time constant.

bridgekeeper · 2025-10-10T13:03:00Z

@MaxXSoft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

MaxXSoft · 2025-10-14T06:18:53Z

Hi @eme64, thanks for your review. I've updated the IR test to ensure that range checks work with the constant folding.

Do you have any other suggestions for this patch?

eme64

@MaxXSoft Ok, now it looks really good. I have one minor nit.

Running some internal testing now.

eme64 · 2025-10-24T15:53:50Z

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java

+        LIMITS_32_0 = INTS_32.next();
+        LIMITS_32_1 = INTS_32.next();
+        LIMITS_32_2 = INTS_32.next();
+        LIMITS_32_3 = INTS_32.next();
+        LIMITS_32_4 = INTS_32.next();
+        LIMITS_32_5 = INTS_32.next();
+        LIMITS_32_6 = INTS_32.next();
+        LIMITS_32_7 = INTS_32.next();
+
+        LIMITS_64_0 = INTS_64.next();
+        LIMITS_64_1 = INTS_64.next();
+        LIMITS_64_2 = INTS_64.next();
+        LIMITS_64_3 = INTS_64.next();
+        LIMITS_64_4 = INTS_64.next();
+        LIMITS_64_5 = INTS_64.next();
+        LIMITS_64_6 = INTS_64.next();
+        LIMITS_64_7 = INTS_64.next();


Why not assign them directly? You just need to declare the generators first. Would save us a couple of lines.

eme64

Testing passed, code looks good to me too now :)

Thanks for all the work you put into this, really appreciated ☺️

eme64

Nice, even better :)

MaxXSoft · 2025-10-29T09:41:18Z

@eme64 Thank you for the review!

@merykitty @jatin-bhateja Do you have any other suggestions regarding the latest changes in this patch?

Make the type of count leading/trailing zero nodes more precise

0faa209

openjdk bot added the rfr Pull request is ready for review label Jun 23, 2025

openjdk bot added the hotspot-compiler [email protected] label Jun 23, 2025

Use BitsPerX constant instead of sizeof

0d0bb57

Narrow type bound

1cb931b

eme64 reviewed Jun 23, 2025

View reviewed changes

src/hotspot/share/opto/countbitsnode.cpp Outdated Show resolved Hide resolved

eme64 reviewed Jun 23, 2025

View reviewed changes

test/hotspot/jtreg/compiler/c2/irTests/TestCountBitsRange.java Outdated Show resolved Hide resolved

liach reviewed Jun 23, 2025

View reviewed changes

MaxXSoft added 2 commits June 24, 2025 15:36

Fix null checks

1ce8ebb

Move TestCountBitsRange to compiler.c2.gvn

c965311

Merge branch 'master' into enhance-clz-type

2f9bca6

jaskarth reviewed Aug 4, 2025

View reviewed changes

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java Show resolved Hide resolved

MaxXSoft added 3 commits August 6, 2025 11:01

Replace isa_* with is_* and add checks for Type::BOTTOM

db2d822

Add checks for results of all test methods

da805b0

Merge branch 'master' into enhance-clz-type

c9051a0

jatin-bhateja reviewed Aug 6, 2025

View reviewed changes

merykitty reviewed Aug 6, 2025

View reviewed changes

src/hotspot/share/opto/countbitsnode.cpp Outdated Show resolved Hide resolved

src/hotspot/share/opto/countbitsnode.cpp Outdated Show resolved Hide resolved

src/hotspot/share/opto/countbitsnode.cpp Outdated Show resolved Hide resolved

Remove unnecessary code

ce5f869

merykitty approved these changes Aug 7, 2025

View reviewed changes

Add missing test method declarations

68d9938

eme64 suggested changes Aug 18, 2025

View reviewed changes

test/hotspot/jtreg/compiler/c2/gvn/TestCountBitsRange.java Outdated Show resolved Hide resolved

Remove redundant @require in IR test

f1c0b45

openjdk bot removed the ready Pull request is ready to be integrated label Aug 19, 2025

eme64 suggested changes Aug 19, 2025

View reviewed changes

MaxXSoft added 3 commits September 8, 2025 16:27

Add proof of correstness comments

5cfe39b

Add more constant folding tests for CLZ/CTZ

d09d4cb

Add more comments to IR test

42c079f

MaxXSoft added 2 commits September 10, 2025 14:52

Add random range tests

79394a2

Remove redundant import

f5d1e53

eme64 suggested changes Sep 12, 2025

View reviewed changes

jatin-bhateja mentioned this pull request Sep 19, 2025

8365205: C2: Optimize popcount value computation using knownbits #27075

Closed

3 tasks

MaxXSoft added 3 commits October 14, 2025 11:33

Fix constant fold

04f2726

Merge branch 'master' into enhance-clz-type

27feb01

Merge branch 'master' into enhance-clz-type

d7ebc8f

Fix include order

9bb3f7d

eme64 reviewed Oct 28, 2025

View reviewed changes

eme64 approved these changes Oct 28, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Oct 28, 2025

Make code more compact

092d968

eme64 approved these changes Oct 29, 2025

View reviewed changes

openjdk bot added ready Pull request is ready to be integrated and removed ready Pull request is ready to be integrated labels Oct 29, 2025

MaxXSoft requested review from jatin-bhateja and merykitty November 4, 2025 09:46

merykitty approved these changes Nov 4, 2025

View reviewed changes

		return TypeInt::make(count_leading_zeros_int(~ti->_bits._zeros),
		count_leading_zeros_int(ti->_bits._ones),

8360192: C2: Make the type of count leading/trailing zero nodes more precise #25928

Are you sure you want to change the base?

8360192: C2: Make the type of count leading/trailing zero nodes more precise #25928

Conversation

MaxXSoft commented Jun 23, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jun 23, 2025

Uh oh!

openjdk bot commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

merykitty commented Jun 23, 2025

Uh oh!

MaxXSoft commented Jun 23, 2025

Uh oh!

merykitty commented Jun 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

merykitty Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaxXSoft Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bridgekeeper bot commented Jul 22, 2025

Uh oh!

MaxXSoft commented Jul 24, 2025

Uh oh!

jaskarth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jatin-bhateja Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jatin-bhateja Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaxXSoft commented Jun 23, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Jun 23, 2025 •

edited

Loading

openjdk bot commented Jun 23, 2025 •

edited

Loading

mlbridge bot commented Jun 23, 2025 •

edited

Loading

merykitty Jun 23, 2025 •

edited

Loading

MaxXSoft Jun 24, 2025 •

edited

Loading

jatin-bhateja Aug 6, 2025 •

edited

Loading

jatin-bhateja Aug 7, 2025 •

edited

Loading