Stream: git-wasmtime

Topic: wasmtime / Issue #1385 Re-design constant pools


view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 17:19):

abrown opened Issue #1385:

This is an open-ended issue for re-designing Cranelift's constant pools. In #1377 I added the ability to calculate the address of constants using const_addr and to declare constants in function preambles (e..g const42 = [0 1 2...]). Constant pools are still implemented at the function level, though, so there is no coalescing of constant values across functions.

I added the function-level ConstantPool implementation in order to support SIMD constants (which don't fit in the immediate fields of Cranelift's IR). This is not a pressing issue yet, but before other components start using constants, it might be good to discuss:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 27 2020 at 23:44):

abrown labeled Issue #1385:

This is an open-ended issue for re-designing Cranelift's constant pools. In #1377 I added the ability to calculate the address of constants using const_addr and to declare constants in function preambles (e..g const42 = [0 1 2...]). Constant pools are still implemented at the function level, though, so there is no coalescing of constant values across functions.

I added the function-level ConstantPool implementation in order to support SIMD constants (which don't fit in the immediate fields of Cranelift's IR). This is not a pressing issue yet, but before other components start using constants, it might be good to discuss:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 26 2020 at 21:25):

abrown commented on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 26 2020 at 21:25):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 26 2020 at 21:35):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 26 2020 at 22:56):

cfallin commented on Issue #1385:

Hi @abrown -- thanks for the detailed look into this!

MachBuffer::defer_constant is indeed the way forward here; the infra is built to emit constant pools, but just isn't wired up yet.

The API expects the client (so, the lowering code) to allocate its own labels, and specify the label for each constant. So the most straightforward thing to do here would be, for constants in the ConstantPool, make an initial pass over them and allocate labels, keeping them in a table. Then the lookup from constant-pool handle to MachLabel is just an array access. Or, slightly better, we lazily emit deferred constants, and the lookup table holds Option<MachLabel>.

I think we should probably build that first before deduplication at the MachInst-lowering level; I'm not fully convinced that the overhead of a hashmap lookup on every new constant generation is worth the potential code-size reduction (but we should measure).

So I would say we should:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 26 2020 at 23:48):

abrown commented on Issue #1385:

Yeah, I like this better. I'll try it out and see what happens!

view this post on Zulip Wasmtime GitHub notifications bot (Dec 01 2020 at 02:16):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Dec 01 2020 at 02:19):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Dec 02 2020 at 22:39):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:

view this post on Zulip Wasmtime GitHub notifications bot (Dec 02 2020 at 22:39):

abrown edited a comment on Issue #1385:

@cfallin, now that I think I understand the new backend better, I think this issue can be moved a bit further:

How things currently work in the new backend:

To simplify the creation of vector constants (all constants, really):

To keep ConstantPool's de-duplicated values AND allow const_addr to retrieve the address of a constant:

When the old backend goes away:


Last updated: Dec 23 2024 at 12:05 UTC