Stream: cranelift

Topic: serde instruction descriptions and tests


view this post on Zulip Sam Parker (Aug 03 2021 at 13:17):

I've been looking out how to improve the aarch64 backend testing and how to do some refactoring in how we describe our instruction and the encoding process. I've now been pointed at the serde crate and it seems like it could be a very useful to do instead of writing raw rust. Has anybody looked into describing instructions, tests, or anything else in the backend using something like JSON?

view this post on Zulip Chris Fallin (Aug 03 2021 at 17:29):

@Sam Parker interesting idea! We could potentially do this, yes; if we have the Decode trait on the Inst then in theory we could build it from JSON. IMHO it's not a huge difference in accessibility to write ~5 lines of rust vs. ~5 lines of JSON for a new instruction encoding test case, so this doesn't seem super-high-priority for me, but maybe others think differently

view this post on Zulip Andrew Brown (Aug 03 2021 at 18:31):

plus there's already the filetest infrastructure: there used to be a test binemit or something like that that we used for checking the encodings of instructions. It could be resurrected if that was more convenient than the Rust unit tests.

view this post on Zulip Andrew Brown (Aug 03 2021 at 18:31):

IMHO, both are at about the same level of ease-of-use

view this post on Zulip Andrew Brown (Aug 03 2021 at 18:32):

I think a good contribution would be to add something to care the encodings of instructions against a separate tool/library (e.g., manually I check many encodings against XED)

view this post on Zulip Chris Fallin (Aug 03 2021 at 18:33):

Yes, +1 to that for sure. When I wrote the initial aarch64 backend I took care to validate against as (all of the instructions' pretty-printed forms were valid as syntax at first) but we never automated that

view this post on Zulip Sam Parker (Aug 04 2021 at 06:22):

Yes, automation would be my main goal - especially for writing tests. There is VIXL (https://github.com/Linaro/vixl) which can generate assemblers, and is a simulator, so I would really like to reuse some output from that to get better test coverage in the backend. I think it would be a bonus if we could have a single place to describe register usage for instructions too, so we don't have to implement both get_regs and map_regs.

AArch32 and AArch64 Runtime Code Generation Library - GitHub - Linaro/vixl: AArch32 and AArch64 Runtime Code Generation Library

view this post on Zulip bjorn3 (Aug 04 2021 at 14:30):

Merging get_regs and map_regs should be possible using a macro I think. Said macro could also directly define the instruction enum and implement the display code.


Last updated: Dec 23 2024 at 13:07 UTC