It occurs to me that compiler optimisation is a prominent exception to this rule. (I don't really want to say 'counterexample', since it doesn't invalidate the sensibleness of the rule in many other contexts.)
In a compiler mid-end, carefully chosen data structure representation can only take you so far. Certainly you can do things like using a flowgraph representation rather than linear code with explicit branches and labels, and using virtual rather than physical regs for as long as possible, and doing SSA if that seems like a good idea, and so on; but sooner or later you still end up with a long list of instructions to do a bunch of things in a particular order and you have to ask yourself, 'What other list of instructions can I prove to be semantically equivalent to this one and judge to have better performance and/or code size?', and there are lots and lots of different techniques for finding such lists and very few of them are immediately obvious given the input data structure.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2014-07-15 14:05 (UTC)In a compiler mid-end, carefully chosen data structure representation can only take you so far. Certainly you can do things like using a flowgraph representation rather than linear code with explicit branches and labels, and using virtual rather than physical regs for as long as possible, and doing SSA if that seems like a good idea, and so on; but sooner or later you still end up with a long list of instructions to do a bunch of things in a particular order and you have to ask yourself, 'What other list of instructions can I prove to be semantically equivalent to this one and judge to have better performance and/or code size?', and there are lots and lots of different techniques for finding such lists and very few of them are immediately obvious given the input data structure.