Damian Heaton (Jul 29 2022 at 14:45): 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.
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
Chris Fallin (Jul 29 2022 at 16:12):we could pretty easily expand that to i128 though, if it's an issue
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.
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)
Chris Fallin (Jul 29 2022 at 16:19):otherwise I can take a quick look at this sometime
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:.
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
Chris Fallin (Jul 29 2022 at 18:31):I'll take a look at this
Anton Kirilov (Jul 29 2022 at 18:40):18446744073709551615 and 0xFFFFFFFFFFFFFFFF should work as well, but in practice most people would probably write -1.
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.
Chris Fallin (Jul 29 2022 at 19:01):yep, working on it now
Chris Fallin (Jul 29 2022 at 19:11):https://github.com/bytecodealliance/wasmtime/pull/4559
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
Anton Kirilov (Aug 01 2022 at 09:49):Thanks!
Last updated: Nov 22 2024 at 16:03 UTC