error: expected: CanDeoptimize() in AOT-DebugX64

[aartbik]

With the new coverage of DartFuzz comes a new failure!
AOT-DebugX64 assert fail:

Isolate (/b/s/w/ir/tmp/t/dart_fuzzAPHZTQ) JIT-O3-DebugSIMARM - AOT-DebugX64: !DIVERGENCE! 1.4:3353051289 (output=false)

fail2:
../../runtime/vm/compiler/backend/il.cc: 4664: error: expected: CanDeoptimize()
version=2.2.1-edge.585eb7f50798e4d0cb1c19e6e126b3c5b5d1ca7b (Fri Mar 8 02:19:06 2019 +0000) on "linux_x64"
thread=30007, isolate=isolate(0x55675d186900)
[0x000055675be65aec] dart::Profiler::DumpStackTrace(void*)
[0x000055675be65aec] dart::Profiler::DumpStackTrace(void*)
[0x000055675c160a92] dart::Assert::Fail(char const*, ...)
[0x000055675bfcfc7d] Unknown symbol
[0x000055675bfac1c6] dart::FlowGraphCompiler::VisitBlocks()
[0x000055675bfb878e] dart::FlowGraphCompiler::CompileGraph()
[0x000055675bf50152] dart::PrecompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
[0x000055675bf527d8] Unknown symbol
[0x000055675bf4c6b4] dart::Precompiler::CompileFunction(dart::Precompiler*, dart::Thread*, dart::Zone*, dart::Function const&)
[0x000055675bf4af0b] dart::Precompiler::ProcessFunction(dart::Function const&)
[0x000055675bf461e3] dart::Precompiler::Iterate()
[0x000055675bf432ed] dart::Precompiler::DoCompileAll()
[0x000055675bf42dd5] dart::Precompiler::CompileAll()
[0x000055675c154052] Dart_Precompile
[0x000055675bb96cbc] dart::bin::main(int, char**)

[aartbik]

Probably the same issue, but including here for completeness. Second failure in same nightly run.

Isolate (/b/s/w/ir/tmp/t/dart_fuzzAPHZTQ) JIT-O3-DebugSIMARM - AOT-DebugX64: !DIVERGENCE! 1.4:389093570 (output=false)

fail2:
../../runtime/vm/compiler/backend/il.cc: 4664: error: expected: CanDeoptimize()
version=2.2.1-edge.585eb7f50798e4d0cb1c19e6e126b3c5b5d1ca7b (Fri Mar 8 02:19:06 2019 +0000) on "linux_x64"
thread=4188, isolate=isolate(0x5624da0ca900)
[0x00005624d7ca1aec] dart::Profiler::DumpStackTrace(void*)
[0x00005624d7ca1aec] dart::Profiler::DumpStackTrace(void*)
[0x00005624d7f9ca92] dart::Assert::Fail(char const*, ...)
[0x00005624d7e0bc7d] Unknown symbol
[0x00005624d7de81c6] dart::FlowGraphCompiler::VisitBlocks()
[0x00005624d7df478e] dart::FlowGraphCompiler::CompileGraph()
[0x00005624d7d8c152] dart::PrecompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
[0x00005624d7d8e7d8] Unknown symbol
[0x00005624d7d886b4] dart::Precompiler::CompileFunction(dart::Precompiler*, dart::Thread*, dart::Zone*, dart::Function const&)
[0x00005624d7d86f0b] dart::Precompiler::ProcessFunction(dart::Function const&)
[0x00005624d7d821e3] dart::Precompiler::Iterate()
[0x00005624d7d7f2ed] dart::Precompiler::DoCompileAll()
[0x00005624d7d7edd5] dart::Precompiler::CompileAll()
[0x00005624d7f90052] Dart_Precompile
[0x00005624d79d2cbc] dart::bin::main(int, char**)

[aartbik]

Problem arises with a speculative Unbox introduced by SelectRepresentations(). Note that this looks familiar, from the bug where an unbox changes its CanDeoptimize() status. Except here, there is never an environment.

#35335

[aartbik]

Since this is now yet another time we are hitting issues after InsertConversion() with a combination of environment, representation, speculative flag, would you mind having a look @mraleph . This code seems rather fragile. I am attaching a reproducer.

[aartbik]

fuzz857410467.dart.txt

[mraleph]

I will be taking a look at this tomorrow - I think I am at the point where I believe that we probably should just always keep IR legal with respect to representations instead of inserting convertions lazily. Amount of bugs we hit with the current approach is just too high.

[aartbik]

+1 on that, having a "strongly typed" IR is just so much easier to reason about and will make it possible to use the graph-checker to assert soundness during all stages

[mraleph]

I have started to look at this today and discovered that we have a bug lurking in Type Propagation pass for around 1.5 years which causes this. When I look at the guilty unbox instruction I see graph like this:

v3075 <- phi(v5558, v3037) alive [-9223372036854775808, 9223372036854775807] int64 T{int}
...
v26806 <- BoxInt64(v3075) [-9223372036854775808, 9223372036854775807] T{int}
...
v27862 <- Unbox(v26806 T{int})
...
v4962 <- phi(v27864 T{_Double}, v27862 T{int}) alive double T{_Double}

v27862 is the instruction that blows up.

Where did this unbox originate? It originates from unboxing of the phi v4962 - we are quite conservative in unboxing phis, so in general we should only unbox when phi has a prove "good" type.

However notice that v4962 has non-sensical type: it's a join of _Double and int - which should be at best num (or Object) and not _Double.

How did it end up with a type like that?

Well it turns out that v27862 has a reaching type at use at v4962 which is disconnected from actual type of v27862 - it is a Type object that originated from previous type propagations, and it is actually owned by phi v3075.

During type propagation type of v3075 is reset to None so instead of computing join of _Double and int we end up computing join of _Double and None which is _Double. v4962 is not in direct use list of v3075 so we don't recompute type of v4962 when type of v3075 changes. Type of v27862 is actually always an int.

I think this was an unexpected consequence of the change 3cc0cea

I am still trying to figure out how to properly solve this.

[aartbik]

@mraleph any progress on this? DartFuzz is running red every night just because of this failure, so getting that green again has some urgency. You want me to retake ownership?

[mraleph]

I had prototyped a fix, but has caused some other failures and I did not have a chance to debug them yet. I am planning to return to this a bit later this week.