RFC notifications bot (Aug 05 2021 at 20:42): RFC notifications bot (Aug 05 2021 at 20:42):cfallin opened PR #13 from cranelift-isel-pre-rfc to main:
Summary
This pre-RFC aims to describe the case for developing or adopting a DSL to write instruction selection/lowering rules in Cranelift backends, and to introduce discussion points.
The goal is not (yet) to design a concrete DSL and start work. Rather, the goal here is to collect requirements, discuss different design choices and how they might work in our context, and generally to see what the community thinks about this and what folks might prefer.
RFC notifications bot (Aug 05 2021 at 21:03):bjorn3 submitted PR review.
RFC notifications bot (Aug 05 2021 at 21:03):bjorn3 created PR review comment:
Removing
InstructionFormatin favor of a big enum with a single variant for each instruction would already help with this even if there is no DSL by making it easy to match on said enum instead of the opcode, which allows binding the fields.
RFC notifications bot (Aug 05 2021 at 21:09):cfallin updated PR #13 from cranelift-isel-pre-rfc to main.
RFC notifications bot (Aug 05 2021 at 21:10):bjorn3 submitted PR review.
RFC notifications bot (Aug 05 2021 at 21:10):bjorn3 created PR review comment:
I think that even after the migration is complete it should be possible to write arbitrary code for the output generation, but not necessarily the input pattern matching. This would allow for complex output code to handle for example turning fixed divisions into multiplications or shifts while still preserving analyzability and optimizability of the patterns if desired.
RFC notifications bot (Aug 05 2021 at 21:11):cfallin updated PR #13 from cranelift-isel-pre-rfc to main.
RFC notifications bot (Aug 05 2021 at 21:31):fitzgen submitted PR review.
RFC notifications bot (Aug 05 2021 at 21:31):fitzgen submitted PR review.
RFC notifications bot (Aug 05 2021 at 21:31):fitzgen created PR review comment:
Related to verification efforts: I think we should call out superoptimization as something we would like to support for our isel. We should be able to do the superoptimization offline, based on CLIF patterns that we've harvested from real world programs, and then take the learned CLIF->vcode pairs and dump them into our new DSL. We should be able to effectively fold the preopt pass (and many more peepholes!) into isel lowering.
This would give us
- better compilation throughput because we have fewer passes over the clif,
- correct by construction CLIF->vcode patterns, and
- optimal (according to some cost function) code generation for these CLIF->vcode patterns.
RFC notifications bot (Aug 06 2021 at 00:16):cfallin submitted PR review.
RFC notifications bot (Aug 06 2021 at 00:16):cfallin created PR review comment:
That's a good point, for sure!
I would hope that the format in which we express our basic lowering patterns is general enough to support arbitrary superoptimizer-derived patterns (i.e., if this is not even technically possible then something is very wrong), so in practice it seems this boils down to, I think:
- We should have or build a translator/bridge from a superoptimizer format into the lowering DSL (like
peepmatic-souper)- We should ensure that the whole infrastructure supports the "enormous pile of complex rules" case efficiently
RFC notifications bot (Aug 06 2021 at 00:19):cfallin submitted PR review.
RFC notifications bot (Aug 06 2021 at 00:19):cfallin created PR review comment:
Right, there are a number of cases where "little building block of arbitrary logic" is useful. Creation of immediate operands is another good example: aarch64 has a very interesting logical-immediate format that can support only some values, with a complex algorithm to derive it. We'd want to make that a "primitive" in some sense by calling out to the existing implementation.
RFC notifications bot (Aug 06 2021 at 00:24):cfallin submitted PR review.
RFC notifications bot (Aug 06 2021 at 00:24):cfallin created PR review comment:
Possibly, but that's probably an orthogonal change to consider; or rather, it would make more sense to think about concrete quality-of-life refactors like this if we decide not to do a DSL, since whether to do a DSL is the high-order bit for developer experience.
RFC notifications bot (Aug 06 2021 at 17:18):fitzgen submitted PR review.
RFC notifications bot (Aug 06 2021 at 17:18):fitzgen created PR review comment:
Exactly, well said :)
RFC notifications bot (Aug 19 2021 at 05:51):cfallin closed without merge PR #13.
Last updated: Dec 23 2024 at 12:05 UTC