Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table length check - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - call_indirect null check after fetchin - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.
Bug 1340235 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table length check - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - call_indirect null check after fetching code pointer - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.
Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table bounds check (bug 1625891) - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - call_indirect null check after fetching code pointer (bug 1709578) - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change (bug 1639153) I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.
Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table bounds check (bug 1625891) - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - not an issue because these (re)loads are invariably followed by a call, and it is faster to reload than to save+restore? - far from clear that these loads are dependent any more, the base and length are stored separately in the tls - call_indirect null check after fetching code pointer (bug 1709578) - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change (bug 1639153) I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.
Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table bounds check (bug 1625891) - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - not an issue because these (re)loads are invariably followed by a call, and it is faster to reload than to save+restore? - far from clear that these loads are dependent a lot of the time, the tls is more or less assumed to be in a register already, would be good to drill down on this - call_indirect null check after fetching code pointer (bug 1709578) - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change (bug 1639153) I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.
Summarizing the issues from above (without knowing whether they have been resolved or not; edits coming): - emscripten compile with EMULATED_FUNCTION_POINTERS=1 to get better code - table bounds check (bug 1625891) - table base and table length reloaded from memory, not commoned by Ion; dependent load issue - not an issue because these (re)loads are invariably followed by a call, and it is faster to reload than to save+restore? - table base and length could be changed by the call? - far from clear that these loads are dependent a lot of the time, the tls is more or less assumed to be in a register already, would be good to drill down on this - call_indirect null check after fetching code pointer (bug 1709578) - call_indirect signature check - call_indirect pessimizes by assuming an instance / context change (bug 1639153) I'm taking this for now in order to perform a new assessment and file necessary dependent bugs.