This might be a backwards way of going about this.
Ultimately one of our highest priorities as a patching compiler is code size. The instruction selector has a lot of control about this, the allocator/scheduler almost none. Eventually we intend to have them more integrated.
The one big thing we do that does effect code size is peephole optimization. In particular mov R0 R0 style patterns get fused out we could have other kinds of fusion patterns.
We could internalize these into the allocator/scheduler as part of the objective function. Each peephole pattern has some code size reduction associated to it. An objective function that captures code size is then max sum has_pattern * code_size_reduction.
This is not orthogonal to the concerns of the instruction selector, nor the to-be-implemented notion of "optional" instructions.
This might be a backwards way of going about this.
Ultimately one of our highest priorities as a patching compiler is code size. The instruction selector has a lot of control about this, the allocator/scheduler almost none. Eventually we intend to have them more integrated.
The one big thing we do that does effect code size is peephole optimization. In particular
mov R0 R0style patterns get fused out we could have other kinds of fusion patterns.We could internalize these into the allocator/scheduler as part of the objective function. Each peephole pattern has some code size reduction associated to it. An objective function that captures code size is then
max sum has_pattern * code_size_reduction.This is not orthogonal to the concerns of the instruction selector, nor the to-be-implemented notion of "optional" instructions.