Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions src/hotspot/share/opto/vtransform.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -1421,8 +1421,9 @@ void VTransformReinterpretVectorNode::print_spec() const {

void VTransformBoolVectorNode::print_spec() const {
VTransformVectorNode::print_spec();
const BoolTest bt(_test._mask);
tty->print(" test=");
BoolTest::mask m = BoolTest::mask(_test._mask & ~BoolTest::unsigned_compare);
const BoolTest bt(m);
tty->print(" test=%s", m == _test._mask ? "" : "unsigned ");
bt.dump_on(tty);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering why we pass the raw mask around instead of keeping it encapsulated in a BoolTest object. Elsewhere I saw code like this:
cond->get_con() & (BoolTest::unsigned_compare - 1)
which seems to be making fragile assumptions about BoolTest internals.

Copy link
Author

@Hamlin-Li Hamlin-Li Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dean-long Yes, I have the same feeling that BoolTest is currently used in a fragile way. The reasons could be, BoolTest itself is by design a struct and expose all its status, and unsigned_compare is indeed not formally supported but needed somewhere e.g. in vector intrinsic, and auto-vectorization (after #28047).
I think it's worth to do more investigation about the refactoring of BoolTest. Besides of several places using unsigned_compare, there are more places using signed BoolTest, it might be helpful to do it in another specific pr, so file https://bugs.openjdk.org/browse/JDK-8371396 to track it, feel free to take it if you already have a solution or idea.

This issue (in fact it's #27942) blocks several other prs in my backlog for a while, e.g. #25336, #25341. It helps to resolve this assert in a quick (although ugly) way. Please kindly let me know how you think about it. Thanks!

}
#endif