Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: restore walkinrange optimization (by moving to SSA) #30645
I’m on my phone, but I suspect that CL 165617 disabled the walkinrange optimization. This makes sense—order now rewrites away OANDAND and OOROR nodes, but those are what walkinrange operates on.
One symptom (I believe) is this:
We have long wanted to move walkinrange to the SSA backend; this is a good motivation.
I’m marking this as a 1.13 release blocker, since IIRC walkinrange is a significant optimization for some hot code (usually parsing/formatting code looking for bytes in a range).
It appears that's the case. Given
on 178a2c4 (a little before that CL):
on a2ace8e (after):
And the generated code contains two
Not sure if this is exactly what you're after but I've been tinkering with some simple logical optimizations for control flow graphs (it's very rough code at the moment, I was just experimenting, but it does work):
This can do optimizations such as this for disjunctions (and similar optimizations for conjunctions):
It also has some optimizations to clean up some uses of
I scheduled it after prove since I was a bit worried it might obscure some facts.
Unfortunately it is quite unpleasant adding new optimizations, especially if you want to add handle multiple bit widths. So I was thinking of extending the rewrite rules a bit so you could write something like this and have a new
Yes, indeed, something like this.
Makes sense. The right place to document that is an entry in passOrder.
Indeed. That’s why I wrote this optimization during walk the first time around. :)
I’m AFK for a while (which is also why I haven’t replied to your comments on the unsafe.Unreachable issue), and it’s not quite obvious to me whether this would work in practice. It’d be lovely if it did. Perhaps we could also move the CMOV optimizations into such a form as well.
In a pinch we could also create a new kind of rewrite rule + rulegen + runner for this kind of optimization, one geared specifically to this kind of optimization.
referenced this issue
Mar 13, 2019
referenced this issue
Mar 22, 2019
I'm going to punt this to 1.14 after all. I finally have a working version, based very loosely on @mundaym's work. But it is definitely non-trivial, and Keith would (very reasonably) prefer to wait for 1.14 for CL 178197, on which my CL depends. I'll see about cleaning up and mailing my CL sooner rather than later, so it can be ready when the tree re-opens or in case of need.