Stream: git-wasmtime

Topic: wasmtime / Issue #2398 Should `const_addr` be removed?

Wasmtime GitHub notifications bot (Nov 12 2020 at 00:47):

abrown opened Issue #2398:

While implementing packed shifts for the old backend, I needed a way to be able to determine the memory address o an offset into a constant emitted by Cranelift. To do this, I added const_addr, an instruction that returns the base address of where the constant is emitted in memory. This pattern followed similar instructions in Cranelift: table_addr, func_addr, stack_addr, heap_addr. In the new backend, I can lower packed shifts without this instruction: since I have more direct control of the compiler machinery, I can figure out the location of the constant in the buffer and emit the appropriate machine-level instructions. const_addr exists because in the old backend this had to be done using CLIF instructions.

I am debating whether to remove this instruction:

• in favor of removing it, fewer instructions would be nice and the primary purpose of this instruction can be fulfilled at a different level
• in favor of keeping it, Cranelift frontend users might find it useful for mask tables (like I did) and the instruction is symmetrical to other *_addr instructions Cranelift provides.

Any strong opinions one way or the other?

Wasmtime GitHub notifications bot (Nov 12 2020 at 00:47):

abrown commented on Issue #2398:

cc: @cfallin, @bjorn3, @sunfishcode

Wasmtime GitHub notifications bot (Nov 12 2020 at 01:34):

cfallin commented on Issue #2398:

It does have a nice symmetry, as you say. On the other hand, it implies that constants are placed in a constant pool in memory; I think it's true that otherwise, constants act as values (that are arguments to certain instructions), right? In other words, const_addr forces us to choose a constant-pool implementation strategy (at least for some constants), whereas otherwise, some targets might choose to generate constants inline, or whatever. Also, at the module level, a code generator can always emit constant data as a global; having two ways to do this (.data/.rodata section and per-function constant pool) is somewhat non-orthogonal.

So I could go either way, but if there are no other users, I might lean in the direction of removing it. Not a super-strong opinion though!

Wasmtime GitHub notifications bot (Nov 12 2020 at 07:40):

bjorn3 commented on Issue #2398:

Also, at the module level, a code generator can always emit constant data as a global

While true, this does prevent optimizations from being able to determine the value of the constants. There are currently no optimizations that use this knowledge, but there may be in the future.

In other words, const_addr forces us to choose a constant-pool implementation strategy (at least for some constants), whereas otherwise, some targets might choose to generate constants inline, or whatever.

If const_addr isn't used on a constant, the backend may choose to generate constants in any way they want.

Last updated: Dec 23 2024 at 12:05 UTC