> It sounds like an idea which would be extremely expensive in compilation > time. Nobody will use a compiler which takes too long to compile. > > We don't need to go as far as you suggest. For example, we could get > better register allocation we if put more time into it, by trying out > several different possibilities. That would be a fairly straightforward > change, almost certainly easier to implement than what you suggest. But > we don't do it, because it would take too long, so nobody would use it. > > You can casually say that nobody cares if the final compilation of > firefox takes 1 CPU year, but in fact people do care, because they want > to test what they ship. > > I don't want to discourage you from exploring this idea if you find it > interesting, but I'm pretty skeptical that it would ever become part of > a gcc distribution. > > Ian > On the other hand, I would put up with compile times that take twice or even 10 times as long (for our final test and final release build) for a 10% speedup of my code. If this is very easy to do, maybe it makes sense to add an optimization flag that specifies how many permutations are allowed to be checked? Brian
