Stream: git-wasmtime

Topic: wasmtime / issue #7139 riscv64: Further optimize constant...

Wasmtime GitHub notifications bot (Oct 03 2023 at 18:45):

github-actions[bot] commented on issue #7139:

Subscribe to Label Action

cc @cfallin, @fitzgen

<details>
This issue or pull request has been labeled: "cranelift", "isle"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Oct 04 2023 at 09:50):

a1phyr commented on issue #7139:

Do you have a idea of what causes the failure ? I don't understand why the sign bit is set in these tests.

A simple function loading the constant outputs the right code:

function %f() -> f64 {
block0:
  v0 = f64const 0xf64.0
  return v0
}

; VCode:
; block0:
;   lui a0,-518695
;   slli a2,a0,31
;   fmv.d.x fa0,a2
;   ret
;
; Disassembled:
; block0: ; offset 0x0
;   lui a0, 0x815d9
;   slli a2, a0, 0x1f
;   fmv.d.x fa0, a2
;   ret

Wasmtime GitHub notifications bot (Oct 04 2023 at 11:28):

afonso360 commented on issue #7139:

I think this might be because lui for RISC-V 64bit sign extends the immediate after placing it in the register.

This is the expression that lui computes:

x[rd] = sext(immediate[31:12] << 12)

The immediate has the MSB set, and since we don't fully shift immediate all the way to the top we are observing the sign extension.

Wasmtime GitHub notifications bot (Oct 04 2023 at 11:31):

afonso360 edited a comment on issue #7139:

I think this might be because lui for RISC-V 64bit sign extends the immediate after placing it in the register.

This is the expression that lui computes:

x[rd] = sext(immediate[31:12] << 12)

The immediate has the MSB set, and since we don't fully shift all the way to the top we are observing the sign extension.

Wasmtime GitHub notifications bot (Oct 04 2023 at 11:31):

afonso360 edited a comment on issue #7139:

I think this might be because lui for RISC-V 64bit sign extends the immediate after placing it in the register.

This is the expression that lui computes:

x[rd] = sext(immediate[31:12] << 12)

The immediate has the MSB set, and since we don't fully shift all the way to the top we are observing the sign extension bit.

Wasmtime GitHub notifications bot (Oct 04 2023 at 11:32):

afonso360 edited a comment on issue #7139:

I think this might be because lui for RISC-V 64bit sign extends the immediate after placing it in the register.

This is the expression that lui computes:

x[rd] = sext(immediate[31:12] << 12)

The immediate has the MSB set, and since we don't fully shift all the way to the top we are observing the sign extension bit.

---

This test might show what is happening slightly better:

test run
target riscv64

function %iconst() -> i64 {
block0:
  v0 = iconst.i64 0x0000_40AE_C800_0000
  return v0
}

; run: %iconst() == 0x0000_40AE_C800_0000
;; we get        == 0xFFFF_C0AE_C800_0000

Wasmtime GitHub notifications bot (Oct 04 2023 at 11:42):

afonso360 edited a comment on issue #7139:

I think this might be because lui for RISC-V 64bit sign extends the immediate before placing it in the register.

This is the expression that lui computes:

x[rd] = sext(immediate[31:12] << 12)

The immediate has the MSB set, and since we don't fully shift all the way to the top we are observing the sign extension bit.

---

This test might show what is happening slightly better:

test run
target riscv64

function %iconst() -> i64 {
block0:
  v0 = iconst.i64 0x0000_40AE_C800_0000
  return v0
}

; run: %iconst() == 0x0000_40AE_C800_0000
;; we get        == 0xFFFF_C0AE_C800_0000

Wasmtime GitHub notifications bot (Oct 04 2023 at 12:18):

a1phyr commented on issue #7139:

Oh I missed that ! Thanks a lot !

Wasmtime GitHub notifications bot (Oct 04 2023 at 13:09):

a1phyr commented on issue #7139:

Note: this does not work for constants like 0xf7fff00000000000 but that would significantly complicate the code.

Last updated: Oct 23 2024 at 20:03 UTC