Ian Lance Taylor <ian@airs.com> writes: > I agree that gcc is not well designed to cope with an accumulator > architecture. Reload can't cope.
I've had a fair amount of success with the approach I initially posted (perturbing the emission order of reloads based on dependencies between the operand they are associated with). It's still pretty fragile in the sense that even a tiny mistake in something like the constraints will cause reload to barf, but I guess that's to be expected. The code produced seems pretty reasonable too (with almost no peepholes at all); for instance it will allocate a variable to the accumulator in the odd case where that's possible. [I don't know if this is the sort of thing that's viable for merging into standard gcc, but maybe a simpler approach based on a backend hook or something would be.] I gotta admit though, by now I thoroughly hate the gcc reload code... -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))
