Wasmtime GitHub notifications bot (Apr 17 2020 at 17:13): Wasmtime GitHub notifications bot (Apr 17 2020 at 17:13):cfallin opened Issue #1539:
Right now, the
vcodefiletest matches the pretty-printed assembly with the filecheck directives. To test the new aarch64 backend, we've written a bunch of filetests that match against a golden compilation. This works for now, but is somewhat brittle: if regalloc heuristics change which registers are used, the tests need to be updated. In addition, it requires us to match the whole function body to ensure that nothing else was generated, when all we really want to do is to assert that a particular operation was implemented by only these N instructions. We should look into porting or building an equivalent of the old backend's "assert this instruction has this encoding" functionality, and its register constraints that make tests more robust.
Wasmtime GitHub notifications bot (Apr 17 2020 at 17:13):cfallin labeled Issue #1539:
Right now, the
vcodefiletest matches the pretty-printed assembly with the filecheck directives. To test the new aarch64 backend, we've written a bunch of filetests that match against a golden compilation. This works for now, but is somewhat brittle: if regalloc heuristics change which registers are used, the tests need to be updated. In addition, it requires us to match the whole function body to ensure that nothing else was generated, when all we really want to do is to assert that a particular operation was implemented by only these N instructions. We should look into porting or building an equivalent of the old backend's "assert this instruction has this encoding" functionality, and its register constraints that make tests more robust.
Wasmtime GitHub notifications bot (Apr 17 2020 at 17:13):cfallin labeled Issue #1539:
Right now, the
vcodefiletest matches the pretty-printed assembly with the filecheck directives. To test the new aarch64 backend, we've written a bunch of filetests that match against a golden compilation. This works for now, but is somewhat brittle: if regalloc heuristics change which registers are used, the tests need to be updated. In addition, it requires us to match the whole function body to ensure that nothing else was generated, when all we really want to do is to assert that a particular operation was implemented by only these N instructions. We should look into porting or building an equivalent of the old backend's "assert this instruction has this encoding" functionality, and its register constraints that make tests more robust.
Wasmtime GitHub notifications bot (Apr 17 2020 at 17:28):bjorn3 commented on Issue #1539:
Did you know about the regex match functionality of filetest?
Wasmtime GitHub notifications bot (Apr 17 2020 at 17:42):alexcrichton commented on Issue #1539:
FWIW one technique which has worked out really well for the Rust project and others I've seen is to have exhaustive assertions about the output (like it seems you're describing is the current state today), but also having a way to auto-update the assertion. This means that at a glance you can always see the complete output of something (such as the full function in all its glory) but if you make a minor tweak to epilogue generation you can easily update the whole test suite. Reviewing is generally quite easy too because you're either looking at something entirely new in which case you can review it in detail, or you're reviewing changes to what was already there so you can easily spot things which may have accidentally changed but shouldn't have.
The way this typically works is there's some sort of opt-in "bless" option. With rust-lang/rust it's
./x.py test --blessbut with some projects I've worked on it's justBLESS=1 cargo test. My workflow is generally to write a test and then always useBLESS=1, reviewing the output manually to make sure it looks ok.I'd be happy to help prototype this if folks think it's a good idea.
Wasmtime GitHub notifications bot (Apr 18 2020 at 00:21):cfallin labeled Issue #1539:
Right now, the
vcodefiletest matches the pretty-printed assembly with the filecheck directives. To test the new aarch64 backend, we've written a bunch of filetests that match against a golden compilation. This works for now, but is somewhat brittle: if regalloc heuristics change which registers are used, the tests need to be updated. In addition, it requires us to match the whole function body to ensure that nothing else was generated, when all we really want to do is to assert that a particular operation was implemented by only these N instructions. We should look into porting or building an equivalent of the old backend's "assert this instruction has this encoding" functionality, and its register constraints that make tests more robust.
Wasmtime GitHub notifications bot (Sep 10 2020 at 16:39):akirilov-arm commented on Issue #1539:
This issue is going to be a major headache for any attempt to fix #1148 in the AArch64 backend.
Last updated: Nov 22 2024 at 16:03 UTC