Enable the IR checker post optimizer with RT longs #5077
Conversation
c527a00 to
256a2f4
Compare
|
It looks like the change in subtyping checks (3rd commit) causes long literals to become allocated as RT long: $c_jl_Math$.prototype.multiplyExact__J__J__J = (function(a, b) {
var ahi = b.RTLong__f_hi;
if (((ahi === 0) ? (b.RTLong__f_lo !== 0) : (ahi > 0))) {
- var this$1 = $m_RTLong$();
- var lo = this$1.divideImpl__I__I__I__I__I((-1), 2147483647, b.RTLong__f_lo, b.RTLong__f_hi);
- var hi = this$1.RTLong$__f_org$scalajs$linker$runtime$RuntimeLong$$hiReturn;
+ var this$1 = new $c_RTLong((-1), 2147483647);
+ var this$2 = $m_RTLong$();
+ var lo = this$2.divideImpl__I__I__I__I__I(this$1.RTLong__f_lo, this$1.RTLong__f_hi, b.RTLong__f_lo, b.RTLong__f_hi);
+ var hi = this$2.RTLong$__f_org$scalajs$linker$runtime$RuntimeLong$$hiReturn;
var ahi$1 = a.RTLong__f_hi;
if (((ahi$1 === hi) ? (((-2147483648) ^ a.RTLong__f_lo) > ((-2147483648) ^ lo)) : (ahi$1 > hi))) {
var overflow = true;I'm trying to identify where the "offending" subtyping check is in the optimizer. |
|
I have not gotten to a conclusion here yet. But it seems the issue is due to casts inserted on the receiver when inlining method calls: We need these when, say, calling |
To enable the IRChecker, we only want to consider RuntimeLong equivalent to BoxedLong when we'll end up removing that type information from the IR. In practice, this is during instance checks.
To keep the IR checker happy, we insert casts at method boundaries that cast RuntimeLongs back to LongType. The first two commits in this PR are not strictly necessary. However, I felt they significantly help understanding of what the optimizer is doing.
|
I have managed to fix the execution tests: the claim that we never do an I have not figured out yet what causes long literals to be stack allocated rather than inlined like before. |
The first two commits are not strictly necessary. However, I felt they significantly help understanding of what the optimizer is doing.