cmd/compile: move arch-specific rewrite rules and ops into arch-specific packages #20104
Comments
Some of these functions are arch-specific (e.g. fitsARM64Offset), so for those this would be a win.
It's really nice to have all the ops in a single table & namespace. For instance, schedule.go:schedule references all of the LoweredGetClosurePtr ops. How would you do that in this new world? (Maybe a bad example, as the closure ptr ops probably deserve a separate flag in the opInfo struct.) I'm not convinced this will be worth it. It's a fair amount of churn and at least I'm not feeling the pain of the current setup right now. |
A flag or perhaps a function.
Fair enough. I'll back-burner it for now.
FWIW, my main motivations is compile times--I think it could help significantly, particular as the number of supported architectures grow. |
You mean compile time of the compiler, right? Not general compile time. |
Right. Cycle time for us. |
andybons
added
NeedsFix
|
Inspired by #27739, I took another quick and dirty stab at this. I left the ops in package SSA and moved only generated code for rewrite rules. There's an unsolved problem around constructing ssa configs for ssa tests, but the rest works and passes toolstash-check -all. It speeds up make.bash on my laptop by 10%, despite the fact that it also disabled a bootstrapping optimization to avoid compiling rules for other architectures during initial optimization. Restoring that would further speed up make.bash. |
gopherbot
added
the
compiler/runtime
Right now, all the .rules files, all the generated code, and all the ops are in package ssa. This monolith has a few downsides: It seems a bit semantically incorrect, and it contributes to issues like #20084, and it makes rebuilding the compiler slower when working on the ssa package.
I'd like to move all the arch-specific stuff into cmd/compile/internal/ARCH. This is non-trivial and does have costs. Rough proposed plan:
Export all functions used by rewrite rules, so that they can be called from outside package ssa. There's a lot of this, including API surface we might normally keep private.
Everywhere we refer to arch-specific ops in package ssa, add some form of generalization.
Set up registration hooks for the value and block rewriters, must as we do now for SSAMarkMoves.
Move .rules and ops files to package ssa and teach rulegen about that. Within the generated files, do
import . "cmd/compile/internal/ssa"to avoid having the teach rulegen to dossa.NewValuefor arch rules but justNewValuefor generic rules. This will also reduce churn in the rules files themselves.I think that's all that needs doing, but we might find more along the way; I started on this but it was big enough I wanted to discuss first.
Comments?
cc @mdempsky @bradfitz @randall77
The text was updated successfully, but these errors were encountered: