Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't have any effect because there is a single specialization instance possible for this node, so no way to trigger multiple and Node#reportPolymorphicSpecialize().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I confirmed that there is no code generated related to the annotation with this change (I used
graal
master, but I don't think that makes a difference).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you make
WriteObjectFieldNode
go polymorphic? I didn't see the extra splits until then. I may very well have it wrong, but I saw a bunch ofInteger
splits from theargc
checks in cext_ruby go away after I made this change. But, I'm misattributing the changes, we can close this out.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't try, no, I just looked at whether this annotation changed anything to the generated code and it looked like no, so should have no effect. It's a case Truffle should warn for, I filed an internal issue for that.
The Integer splits sounds strange, maybe something is redefining these Integer methods, even if it installs back the original ones after it will still invalidate the Assumptions permanently.
Could also be some
some_integer == some_nonumeric_object
somewhere, and that would end up callingsome_nonumeric_object == some_integer
which could cause splitting.But for these Integer#{==,>=} calls they should always use Inlined*Node, unless these methods are redefined at some point, and these inline nodes like InlinedEqualNode do not even use IntegerNode.EqualNode and both sides should be clearly
int
in that code.