Stream: git-wasmtime

Topic: wasmtime / issue #1067 Bitfield Extract/Create instructions


view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 20:42):

cfallin labeled issue #1067:

This would add two new instructions to cranelift, bextr and bmak. They provide a easy to optimize, and easy to generate mechanism for bitfield manipulation.

bextr

a = bextr target, size, offset

bextr will extract a _n_ bit large field at the provided offset, and return it in a, shifted so that the LSB of the field is also the LSB of a.
a's type is inferred from target

Visual example

offset = 4
size = 4
typeof target = i8

xxxx **** 
\__/----V
0000 xxxx

bmak

a = bmak target, size, offset

bmak will fill a _n_ bit large field at the provided offset with 1s, the rest with 0. The generated field will then be applied to target using a bitwise AND, and the result will be returned in a.
a's type is inferred from target
bmak is designed so that you can simply use a bitwise or to combine the fields.

Visual Example

offset = 2
size = 4
typeof target = i8

xx0101xx
  \__/
  /  \
00010100

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 20:42):

cfallin labeled issue #1067:

This would add two new instructions to cranelift, bextr and bmak. They provide a easy to optimize, and easy to generate mechanism for bitfield manipulation.

bextr

a = bextr target, size, offset

bextr will extract a _n_ bit large field at the provided offset, and return it in a, shifted so that the LSB of the field is also the LSB of a.
a's type is inferred from target

Visual example

offset = 4
size = 4
typeof target = i8

xxxx **** 
\__/----V
0000 xxxx

bmak

a = bmak target, size, offset

bmak will fill a _n_ bit large field at the provided offset with 1s, the rest with 0. The generated field will then be applied to target using a bitwise AND, and the result will be returned in a.
a's type is inferred from target
bmak is designed so that you can simply use a bitwise or to combine the fields.

Visual Example

offset = 2
size = 4
typeof target = i8

xx0101xx
  \__/
  /  \
00010100

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2025 at 18:04):

cfallin commented on issue #1067:

We discussed this during old-issue triage today and agreed that it is probably better to have users implement this behavior with shifts/masks and then pattern-match that during isel if a particular target ISA has a nice instruction for it. This fits better with the general trend of making CLIF a simple core IR, especially as not every ISA has such instructions -- this would have to be re-expanded in backends otherwise, and only after the point that that expansion could be optimized. I'll close this issue but thank you for the discussion!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2025 at 18:04):

cfallin closed issue #1067:

This would add two new instructions to cranelift, bextr and bmak. They provide a easy to optimize, and easy to generate mechanism for bitfield manipulation.

bextr

a = bextr target, size, offset

bextr will extract a _n_ bit large field at the provided offset, and return it in a, shifted so that the LSB of the field is also the LSB of a.
a's type is inferred from target

Visual example

offset = 4
size = 4
typeof target = i8

xxxx **** 
\__/----V
0000 xxxx

bmak

a = bmak target, size, offset

bmak will fill a _n_ bit large field at the provided offset with 1s, the rest with 0. The generated field will then be applied to target using a bitwise AND, and the result will be returned in a.
a's type is inferred from target
bmak is designed so that you can simply use a bitwise or to combine the fields.

Visual Example

offset = 2
size = 4
typeof target = i8

xx0101xx
  \__/
  /  \
00010100

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2025 at 19:28):

moonheart08 commented on issue #1067:

We discussed this during old-issue triage today and agreed that it is probably better to have users implement this behavior with shifts/masks and then pattern-match that during isel if a particular target ISA has a nice instruction for it. This fits better with the general trend of making CLIF a simple core IR, especially as not every ISA has such instructions -- this would have to be re-expanded in backends otherwise, and only after the point that that expansion could be optimized. I'll close this issue but thank you for the discussion!

7 years later with a stronger understanding of compilers and architectures, and I agree this is probably the right approach. Yet another issue I didn't remember creating resolved today!


Last updated: Dec 06 2025 at 06:05 UTC