Bugzilla

After some investigation and with considerable hints from Jan, the following
seems to be the case:

(1) MWasmLoadInstanceDataField::congruent is correct, and its alias set
    annotations are correct too.  Also, MWasmCall{Catchable,Uncatchable} has
    (by default) correct alias set annotations.

(2) The problem appears to be caused by an instruction-processing loop [1] in
    the middle of the alias analyser.

    It skips the last insn in every block -- presumably to save time, on the
    basis that no control insn will access memory.  But the introduction of
    MWasmCallCatchable as a control insn breaks that assumption.  For the test
    case listing in comment 10, this causes it to ignore

      11 = None.wasmcallcatchable 2

    hence not invalidating the first MWasmLoadInstanceDataField, and so
    causing it to be incorrectly used as a replacement for the second one.

(3) Allowing the loop to visit the last insn at least fixes the comment 10
    test case.  Tentative patch to follow; not suitable for landing and needs
    more testing.

[1] https://searchfox.org/mozilla-central/source/js/src/jit/AliasAnalysis.cpp#190-192

After some investigation and with considerable hints from Jan, the following
seems to be the case:

* MWasmLoadInstanceDataField::congruent is correct, and its alias set
    annotations are correct too.  Also, MWasmCall{Catchable,Uncatchable} has
    (by default) correct alias set annotations.

* The problem appears to be caused by an instruction-processing loop [1] in
    the middle of the alias analyser.

    It skips the last insn in every block -- presumably to save time, on the
    basis that no control insn will access memory.  But the introduction of
    MWasmCallCatchable as a control insn breaks that assumption.  For the test
    case listing in comment 10, this causes it to ignore

      11 = None.wasmcallcatchable 2

    hence not invalidating the first MWasmLoadInstanceDataField, and so
    causing it to be incorrectly used as a replacement for the second one.

* Allowing the loop to visit the last insn at least fixes the comment 10
    test case.  Tentative patch to follow; not suitable for landing and needs
    more testing.

[1] https://searchfox.org/mozilla-central/source/js/src/jit/AliasAnalysis.cpp#190-192