You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current indy logic for binding calls that appear to be operations against a fixnum, we only have a fast, inlinable path for the success case. If it turns out the operation is not performed against a fixnum, we follow a slower, non-inlinable path.
Calls that appear to be fixnum operators are of the form , as in the following examples:
a = b + 1
a = b * 1
a = b << 8
In cases like these, we will optimize the call to go straight into the versions of these methods on RubyFixnum that receive long rather than IRubyObject for the second operand. The guard is a simple "instanceof RubyFixnum" check.
If the guard fails, we permanently fall back to a version that mimics the old CachingCallSite, actively checking the cache entry for validity each time. This logic is much slower than standard indy dispatch and does not allow the target method to inline.
This comes into play in the Benchmarks Game "pidigits" code, since fixnums eventually roll over into bignums and the operators start failing. There are likely many other cases out there where a literal fixnum is added, subtracted, etc with a float, rational, bignum, or other value, or appended into an array.
The text was updated successfully, but these errors were encountered:
This is a valid issue but between Graal and IR work this is not really specifically an indy issue. Or at least it overlaps with other avenues of optimization now.
In the current indy logic for binding calls that appear to be operations against a fixnum, we only have a fast, inlinable path for the success case. If it turns out the operation is not performed against a fixnum, we follow a slower, non-inlinable path.
Calls that appear to be fixnum operators are of the form , as in the following examples:
In cases like these, we will optimize the call to go straight into the versions of these methods on RubyFixnum that receive long rather than IRubyObject for the second operand. The guard is a simple "instanceof RubyFixnum" check.
If the guard fails, we permanently fall back to a version that mimics the old CachingCallSite, actively checking the cache entry for validity each time. This logic is much slower than standard indy dispatch and does not allow the target method to inline.
This comes into play in the Benchmarks Game "pidigits" code, since fixnums eventually roll over into bignums and the operators start failing. There are likely many other cases out there where a literal fixnum is added, subtracted, etc with a float, rational, bignum, or other value, or appended into an array.
The text was updated successfully, but these errors were encountered: