Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: add special rewrite rule syntax for op renaming #36380
A lot of rewrite rules are of the form:
(Op [c] a b) -> (LoweredOp [c] a b)
I propose we add a special form of rewrite rule for this common case. Something like:
(Op ...) -> (LoweredOp ...)
Upsides to having special machinery:
Opinions? I’d like to clear the design before writing the code.
Seems do-able. For example, we could pull reg info out of opcodeData and instead give each arch a generic and a lowered reginfo table, and wire them up in config.go the way we do rewrite rules.
There are some other complications. For example, in regalloc, we check whether an op is generic for some wasm decisions about putting things on the stack. There may be other items like that that need to found and reworked.
We can do this incrementally, but it'll still create a lot of code churn, particularly in the rewrite rules.
We'd still have some op-only rewriting, but maybe not enough to care about. Example:
No, but mostly.
Not really. The semantics are different; a plain rule like this is actually zeroing+an op change. And detecting that nothing needs zeroing is hard. I actually tried this and decided that an explicit rule is way easier and cleaner.
Ah. I apologize. I should have given as my initial example
Here are the amd64 op-changing rewrite rules I am aware of. LoweredX ops are 6 out of 110.
This change introduces a new syntax for rewrite rules that only change a Value's Op. See #36380 for more discussion. Updating rewrite rules to use ellipses will happen in follow-up CLs. Change-Id: I8c56e85de24607579d79729575c89ca80805ba5c Reviewed-on: https://go-review.googlesource.com/c/go/+/213898 Run-TryBot: Josh Bleecher Snyder <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Keith Randall <email@example.com>