New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: add special rewrite rule syntax for op renaming #36380
Comments
I feel like I'd rather get rid of the Lowered* ops altogether. |
Does this only affect lowering rules? We could also consider doing this in parts. For example, we could recognise the cases where just the op changes, without touching the rule syntax at all. |
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:
would become:
|
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. |
I wasn't suggesting that we not lower Sub64 to SUBQ. |
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.
|
Change https://golang.org/cl/213898 mentions this issue: |
It turned out to be easy to implement, so I whipped up CL 213898 as an experiment, to make this discussion concrete. |
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 <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
This happened. |
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 ...)
Or maybe
*
instead of...
? The rulegen engine would recognize this and generate just:v.Op = LoweredOp
.Upsides to having special machinery:
Opinions? I’d like to clear the design before writing the code.
cc @randall77 @mvdan
The text was updated successfully, but these errors were encountered: