Veverak (Dec 18 2021 at 08:36): Veverak (Dec 18 2021 at 08:36):The 'load' instruction always loads a value in native endian regardless of the endianness I set in the memory flags. If this feature isn't implemented in the backend, isn't it better to abort compilation than to generate code that reads the wrong value? Now I'm looking for a workaround, and I can't even find an instruction to swap the byte order of a value.
MemFlags says:
In addition, the flags determine the endianness of the memory access. By default, any memory access uses the native endianness determined by the target ISA. This can be overridden for individual accesses by explicitly specifying little- or big-endian semantics via the flags.
The IR clearly indicates the endianness which is ignored:
v1 = load.i16 notrap big v0
The s390x backend is the only backend currently implementing it. This is big endian architecture, so it was necessary to implement wasm little endian memory operations. IMO the othet backends should gain support for it too. Can you open an issue if there isn't one already?
Veverak (Dec 18 2021 at 17:11):Sorry I can't open an issue because I don't have a Github account.
bjorn3 (Dec 18 2021 at 18:45):Forgot about that. Opened https://github.com/bytecodealliance/wasmtime/issues/3625
Chris Fallin (Dec 18 2021 at 18:54):Thanks for raising this; yes, it's an implementation hole at the moment, and we need to fill it out. This sort of thing is what we're hoping to do under the "polish and project maturity" item on the roadmap for next year -- it's just a matter of folks having time
Notification Bot (Dec 19 2021 at 05:06):Veverak has marked this topic as resolved.
Last updated: Dec 23 2024 at 12:05 UTC