corelib_2/bigint_from_test fails on vm-linux-release-ia32-optcounter-threshold-be #32619
Comments
related #32619 Change-Id: Iee23ea5d80f398e7a25b4c77164f327c4cf064ab Reviewed-on: https://dart-review.googlesource.com/47401 Reviewed-by: Alexander Markov <alexmarkov@google.com> Commit-Queue: Zach Anderson <zra@google.com>
mit-mit
added
the
area-core-library
alexmarkov
added
area-vm
|
The test works in default mode, and doesn't work on ia32 if '--optimization-counter-threshold=5' option is specified. This is a miscompilation in VM. Smaller example, independent of BigInt: import "package:expect/expect.dart";
import 'dart:typed_data';
main() {
var multiplicandDigits = new Uint32List.fromList([0, 294967296, 0, 0]);
var accumulatorDigits = new Uint32List.fromList([0, 4, 4, 0, 0, 0]);
var d1 = _mulAdd(multiplicandDigits, 0, accumulatorDigits, 0, 2);
Expect.equals(0, d1);
}
const int _digitBits = 32;
const int _digitMask = (1 << _digitBits) - 1;
const int _halfDigitBits = _digitBits >> 1;
const int _halfDigitMask = (1 << _halfDigitBits) - 1;
int _mulAdd(Uint32List multiplicandDigits, int i, Uint32List accumulatorDigits,
int j, int n) {
int carry = 0;
while (--n >= 0) {
int ml = multiplicandDigits[i] & _halfDigitMask;
int mh = multiplicandDigits[i++] >> _halfDigitBits;
int ph = mh * 4;
int q1 = ((ph & _halfDigitMask) << _halfDigitBits);
int pl = 4 * ml + q1 + accumulatorDigits[j];
carry = (pl >> _digitBits) + (ph >> _halfDigitBits);
accumulatorDigits[j++] = pl & _digitMask;
}
return carry;
}Miscompilation happens due to WidenSmiToInt32 pass in _mulAdd method. WidenSmiToInt32 pass is only used on 32-bit platforms. to Later, result of BinaryInt32Op is boxed: The problem is that there is a missing CheckSmi for v115. /cc @mraleph |
|
I suspect the problem is at this line: Definition* boxed = BoxInstr::Create(from, use->CopyWithType());we probably have stale type on the use. No, disregard this: we do clear type. |
|
Types on uses of BinaryInt32Op are cleared in WidenSmiToInt32 (v115 doesn't have a type in flow graph snippet above). Also, I don't see anything wrong with BoxInt32 - it works as expected. I think the problem is a missing CheckSmi for pre-existing BinarySmiOp which now uses BinaryInt32Op/BoxInt32 after widening. It looks like we don't insert CheckSmi when selecting representations or during widening - only when specializing calls and in inliner. @mraleph, can you clarify your point? |
…trix related #32619 Change-Id: I0fc20f21cf3a6e231e0f3d962f139fd072acf3ab Reviewed-on: https://dart-review.googlesource.com/47540 Reviewed-by: Ryan Macnak <rmacnak@google.com> Commit-Queue: Zach Anderson <zra@google.com>
|
Yes, my first thought was wrong. I think your analysis is correct - optimization does not account for the fact that widening alters the range of the operation, which means that it potentially "invalidates" the code that uses the value. So widening needs to be safe with respect to uses. I think we should just disable this optimization for now and work on replacing it with a proper solution. |
|
The test "magically" started to pass since https://ci.chromium.org/buildbot/client.dart/vm-linux-release-ia32-optcounter-threshold-be/10024. Any ideas why? It passes on my local machine too. |
|
CL to disable widening: https://dart-review.googlesource.com/c/sdk/+/47661 /cc @mraleph |
|
I am not surprised that some things regressed - we did implement it for a reason. I think it is worth investing in reimplementation of this optimization, but I would like us to do it as part of a cohesive strategy for optimizing integer arithmetic - right now we have a patch work of different things. |
|
@aam, the original reproduction relied on BigInt code which was changed in f2806ab. I'm not able to reproduce the problem using corelib_2/bigint_from_test test after that change. So I think we can update the status file to make bot green again. The problem with incorrect optimization is still there, and it can be reproduced with regression test which I extracted from BigInt code (see https://dart-review.googlesource.com/c/sdk/+/47661). So this issue is still open. |
|
@alexmarkov, f2806ab reenabled intrinsics, probably bypassing the Dart code that is improperly optimized. You could try to pass the flag --no-intrinsify to see if the issue reappears. |
|
Even with --no-intrinsify, the test still passes. Beside reenabling intrinsics, the CL above also blocks intrinsifiable functions from being inlined. This probably prevents the buggy optimization from being applied. Since you have an independent test reproducing the issue, it does not really matter. |
Bug: #32619 Change-Id: I81bde9c9121ff4f47821d3fb6ee34520bb767e92 Reviewed-on: https://dart-review.googlesource.com/48087 Reviewed-by: Alexander Markov <alexmarkov@google.com> Commit-Queue: Alexander Aprelev <aam@google.com>
This optimization is a dead code: it was disabled since 2018 (97ffcd9) because it incorrectly changes Smi instructions to Int32 instructions without accounting for a larger range of the result which may not be expected by uses of the instruction. TEST=ci Issue: #32619 Change-Id: Ice34ff36929c998e7d1a1584e061834119636e2a Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364965 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Slava Egorov <vegorov@google.com>
/cc @lrhn @crelier @alexmarkov
The text was updated successfully, but these errors were encountered: