<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - B3 should efficiently emit great code for WebAssembly property accesses and bounds checks"
href="https://bugs.webkit.org/show_bug.cgi?id=163171#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - B3 should efficiently emit great code for WebAssembly property accesses and bounds checks"
href="https://bugs.webkit.org/show_bug.cgi?id=163171">bug 163171</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=163171#c2">comment #2</a>)
<span class="quote">> I think your strategy does not work with the design of wasm. You cannot sink
> WasmBoundsCheck(Add(ptr, const), gpr, offset) to WasmBoundsCheck(ptr, gpr,
> offset - const) because that would change the trapping semantics of the
> language. For example if the user wrote the following wasm:
>
> ptr = i32.Add(p, 2024)
> i32.Load(ptr)
>
> if p = 0 - 1024 then this code should not trap but if we sunk that addition
> into the guard page size we would trap since the pointer would appear to be
> out of bounds.</span >
Word. I think that if we wanted to do this, we would do it by versioning the code in B3.
When using bounds checks, we'd emit the check that we want (with the sunken offset), but as an actual branch. The failing path would have a different version of the code in which we do the precise bounds checks. We would duplicate (i.e. version) some path following the check, taking into consideration code size versus profitability heuristics. For example, we would probably always version small loops that contained repeated accesses to some pointer at different offsets that were all within the guard page size.
When using trapping, we could introduce the idea of a trapping MemoryValue block terminal with two successors. The normal successor would be taken when the instruction did not trap, and the other successor would be taken if we trapped (the trap handler would just fiddle the PC to take you to the other path).
We don't have to do any of that now, but boy would it be fun!</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>