WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
173687
ValueRep(DoubleRep(@v)) can not simply convert to @v
https://bugs.webkit.org/show_bug.cgi?id=173687
Summary
ValueRep(DoubleRep(@v)) can not simply convert to @v
Saam Barati
Reported
2017-06-21 19:19:23 PDT
consider this IR: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) some more nodes here ... Because the flow of ValueRep(DoubleRep(@p)) will not produce an Int32, AI proves that the Int32 check will fail. Constant folding phase removes all nodes after @a and inserts an Unreachable after the NewArrayWithSize node. The IR then looks like this: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) Unreachable However, there is a strength reduction rule that tries eliminate redundant conversions. It then converts the program to: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here a: NewArrayWithSize(Int32:@p) Unreachable At runtime, @p will actually be an Int32, so @a will not OSR exit, and we’ll crash. I believe this strength reduction rule is wrong, since it produces different output than if we ran the program without it. However, we clearly want to keep some optimizations for not performing redundant conversions. I think there are conditions under which we can perform this optimization. For example, if @p definitely produces a Double, I think this optimization would be sound.
Attachments
patch
(4.95 KB, patch)
2017-06-22 12:32 PDT
,
Saam Barati
mark.lam
: review+
Details
Formatted Diff
Diff
patch for landing
(4.94 KB, patch)
2017-06-22 12:40 PDT
,
Saam Barati
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Mark Lam
Comment 1
2017-06-21 20:55:39 PDT
<
rdar://problem/32855563
>
Saam Barati
Comment 2
2017-06-22 11:30:19 PDT
This program crashes JSC: ``` let a1 = [1,2,3,4]; delete a1[2]; let a2 = []; a2.length = null; let thingy = {length: 2**55, __proto__: []}; let arrays = [ [10, {}, 20.5, 7821], a2, [10.2, 122.55, 10.22, 12.44], a2, [10,,10,,,20,,,,,50], a1, a2, ]; noInline(Array.prototype.map); let funcs = [ (x) => x, (x) => x, (x) => x, (x) => x, (x) => x, (x) => x, (x) => x, (x) => x, (x) => x, ]; function loop(x) { for (let i = 0; i < x; ++i) { try { if (i > 0 && (i % 1000) === 0) thingy.map(x => x) arrays[i % arrays.length].map(funcs[i % funcs.length]); } catch(e) { } } } loop(100000); ```
Saam Barati
Comment 3
2017-06-22 12:32:15 PDT
Created
attachment 313650
[details]
patch
Mark Lam
Comment 4
2017-06-22 12:37:29 PDT
Comment on
attachment 313650
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=313650&action=review
r=me
> Source/JavaScriptCore/ChangeLog:41 > + and weâll crash. This patch removes this strength reduction rule since it
Please remove the non-ascii char in "we'll".
Saam Barati
Comment 5
2017-06-22 12:40:58 PDT
Created
attachment 313651
[details]
patch for landing
Keith Miller
Comment 6
2017-06-22 14:32:07 PDT
Comment on
attachment 313651
[details]
patch for landing View in context:
https://bugs.webkit.org/attachment.cgi?id=313651&action=review
> Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:221 > // This short-circuits circuitous conversions, like ValueRep(DoubleRep(value)) or > // even more complicated things. Like, it can handle a beast like > // ValueRep(DoubleRep(Int52Rep(value))).
Seems like you should update this comment. It seems quite wrong...
Saam Barati
Comment 7
2017-06-22 16:34:36 PDT
landed in:
https://trac.webkit.org/changeset/218728/webkit
and fixed the comment.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug