Stream: cranelift

Topic: ISLE 64-bit splat_const (AArch64)


view this post on Zulip Damian Heaton (Jul 29 2022 at 14:45):

Discovered an issue with splat_const in ISLE, whereby attempting to load a 64-bit value into an i64x2 using it leads to a parse error: number too large to fit in target type.

This can be worked around by loading the upper and lower halves of the value into two separate vectors and then combining them together, but that is inefficient.
Unfortunately, the phrase "number too large to fit in target type" is not easily found within the source code... It is mentioned here, but I'm not sure that's used by the ISLE compiler.

view this post on Zulip Chris Fallin (Jul 29 2022 at 16:12):

hi @Damian Heaton -- it's unclear to me exactly what the issue is; do you mean writing certain ISLE expressions leads to a parse error when building the ISLE? If so that's probably a result of the fact that all integer constants in ISLE are parsed into i64 values

view this post on Zulip Chris Fallin (Jul 29 2022 at 16:12):

we could pretty easily expand that to i128 though, if it's an issue

view this post on Zulip Damian Heaton (Jul 29 2022 at 16:15):

Yes - so, for example, splat_const -1 (VectorSize.Size64x2) (in practice, any constant using all 64 bits) fails with the aforementioned parse error during ISLE build.

view this post on Zulip Chris Fallin (Jul 29 2022 at 16:19):

OK. If you want to dig into the ISLE compiler yourself I'm happy to review a PR (it may be less scary than that sounds! Change this i64 and this i64 to i128s and then chase the type errors till you've propagated that fully)

A standalone runtime for WebAssembly. Contribute to bytecodealliance/wasmtime development by creating an account on GitHub.
A standalone runtime for WebAssembly. Contribute to bytecodealliance/wasmtime development by creating an account on GitHub.

view this post on Zulip Chris Fallin (Jul 29 2022 at 16:19):

otherwise I can take a quick look at this sometime

view this post on Zulip Anton Kirilov (Jul 29 2022 at 18:24):

IMHO the fact that the -1 constant can't be used in ISLE code is a significant usability issue :smile:.

view this post on Zulip Chris Fallin (Jul 29 2022 at 18:31):

ah -- I just realized this may be because of i64 vs u64; yes, we should parse negatives correctly

view this post on Zulip Chris Fallin (Jul 29 2022 at 18:31):

I'll take a look at this

view this post on Zulip Anton Kirilov (Jul 29 2022 at 18:40):

18446744073709551615 and 0xFFFFFFFFFFFFFFFF should work as well, but in practice most people would probably write -1.

view this post on Zulip Anton Kirilov (Jul 29 2022 at 18:43):

Actually, if we are dealing with a u64 value, both 18446744073709551615 and 0xFFFFFFFFFFFFFFFF should work, and if the type is i64, then both -1 and 0xFFFFFFFFFFFFFFFF should work. Whether -1 should work for u64 is debatable, I suppose, but it's definitely a convenience.

view this post on Zulip Chris Fallin (Jul 29 2022 at 19:01):

yep, working on it now

view this post on Zulip Chris Fallin (Jul 29 2022 at 19:11):

https://github.com/bytecodealliance/wasmtime/pull/4559

The ISLE language's lexer previously used a very primitive i64::from_str_radix call to parse integer constants, allowing values in the range -2^63..2^63 only. Also, underscores to separate digits (...

view this post on Zulip Chris Fallin (Jul 29 2022 at 21:18):

ok that's set to auto-merge so @Anton Kirilov and @Damian Heaton you should have nicer int constants now

view this post on Zulip Anton Kirilov (Aug 01 2022 at 09:49):

Thanks!


Last updated: Dec 23 2024 at 12:05 UTC