Compute label dependencies from immediate sources only

[makachanm]

Phase 2 of buildVariables seeks the whole chain for every cell, so it got quadratic on big function.
Now each cell looks at its immediate sources only and we repeat until nothing changes.

30-48% of JIT compile time is taken for this, so it this patch speeds up reorder cycle shows like this.

phase 2     btree -24%   json -23%   lua -71%   sqlite -63%
JIT total   btree  -6%   json  -7%   lua -37%   sqlite -33%

(I make this patch when doing a test using real-workload jobs in walrus. so this bench is based on real-workloads.)

[zherczeg]

This could be a do-while, isn't it?

[makachanm]

Got it. I'll do it.

[zherczeg]

Could you explain what this patch tries to do? What are the immediate sources?

[makachanm]

Could you explain what this patch tries to do? What are the immediate sources?

Actually, walrus's Phase 2 of buildVariable() is quite inefficient. May can be takes n^2 to find dependency of instructions.

So I tried some chop-off the check range that algorithm does loops. It generate candidates, and do lookup for in that range.

[makachanm]

For a label and a stack slot, the immediate sources are what each branch into that label leaves in that slot.

[zherczeg]

My impression is that these vectors are part of a structure. Can we use less number of vectors which contain a struct member? Something like:

struct SlotData {
rangeStart;
rangeEnd;
constraints;
};
std::vector slotData;

This could reduce the memory allocations.

[zherczeg]

LGTM

[makachanm]

I can't understand why only the armt2 debug is always failing. It can be sperate issue.

[zherczeg]

This is the test: test/regression/segv_onExport.wasm
The output contains garbage.
Could you check the output?

[makachanm]

Weird. That test file looks just okay.

[kulcsaradam]

Weird. That test file looks just okay.

Some project had a similar problem with python in this issue: apache/arrow#46343

You can just ammend your patch without any changes, push again to force the CI to run and it should run normally as I have seen. It does not cause a problem every time and its mainly with the arm platforms in my experience. It might be a qemu error, I am unsure.

[makachanm]

00000000  55 6e 63 61 75 67 68 74  20 45 78 63 65 70 74 69  |Uncaught Excepti|
00000010  6f 6e 3a 20 ef 71 5a 0a                           |on: .qZ.|
exit=255

I think trap is not working correctly in armt2.
Trap throws out unknown strings in error message.

Program received signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 ()
#1  __printf_buffer ()
#3  fprintf ()
#4  main () at src/shell/Shell.cpp:1428
rdi   0x851df9725b07010c

Seems to problem is memory related. But I still cannot understand why x86/RISC-V is acting like normal.

[makachanm]

#0  Walrus::Exception::create (m=...) at /home/maka/Workspace/walrus/src/runtime/Exception.h:36
#1  0x00194b80 in executeWASMComponent (store=..., filename=..., src=...) at /home/maka/Workspace/walrus/src/shell/Shell.cpp:382
#2  0x00199342 in main (argc=..., argv=...) at /home/maka/Workspace/walrus/src/shell/Shell.cpp:1426

#0  Walrus::Exception::releaseRef (this=...) at /home/maka/Workspace/walrus/src/runtime/Exception.h:61
#1  0x00163fe2 in Walrus::Trap::TrapResult::~TrapResult (this=..., __in_chrg=...) at /home/maka/Workspace/walrus/src/runtime/Trap.h:44
#2  0x00194b98 in executeWASMComponent (store=..., filename=..., src=...) at /home/maka/Workspace/walrus/src/shell/Shell.cpp:384
#3  0x00199342 in main (argc=..., argv=...) at /home/maka/Workspace/walrus/src/shell/Shell.cpp:1426

#0  Walrus::Exception::releaseRef (this=...) at /home/maka/Workspace/walrus/src/runtime/Exception.h:61
#1  0x00163fe2 in Walrus::Trap::TrapResult::~TrapResult (this=..., __in_chrg=...) at /home/maka/Workspace/walrus/src/runtime/Trap.h:44
#2  0x00199396 in main (argc=..., argv=...) at /home/maka/Workspace/walrus/src/shell/Shell.cpp:1432
[Inferior 1 (process 417791) exited with code 0377]

Maybe it can be problem of destructor.