Jeffrey Law <[EMAIL PROTECTED]> writes: > > > * expmed.c (expand_mult): If the variable operand is a coprocessor > > > value, use a coprocessor accumulator. > > > > Why? Isn't this an architecture specific decision to make? Iff this > > will ever be useful to other architectures than MEP (which I seriously > > doubt), it could be better for that arch to use a normal mode. > Oh, it could definitely be useful on other architectures; I've done GCC > work on architectures were it would certainly have been advantageous to > have this capability. You could even model the MIPS in this manner and > probably get better code for integer multiply-accumulate operations :-)
Can you expand on that? As far as I can see, this patch only works for code which is written specifically to take advantage of it. If you don't declare your variables using __attribute__ ((mode (COPxx))), then you don't get the coprocessor modes. So it seems that at best this facility would permit somebody to write their code for a specific MIPS implementation and get better code. For anybody who was willing to do that, for MIPS we could provide a similar facility using a builtin function. And actually for MIPS we could provide a similar facility with a machine dependent register classing pass--I did that in the past for this sort of thing. It has the advantage of only requiring a new target hook and a new set_reg_class function, and is thus easy to maintain. I find that I'm still unclear on what this facility is used for. I think I understand that the chip has a main processor and a coprocessor. It is expensive to move data between the two. Both of them have basic arithmetic instructions (and no doubt other stuff as well). Both can run simultaneously. Since we want to run them simultaneously for speed, we want to make sure that values which are going to be used by coprocessor instructions are kept in coprocessor registers as much as possible. So far, so good. But: if I understand the patch, in order to use the coprocessor, the user must write their code using special types. Is that an important and desirable feature? Or is that taking the fact that the compiler doesn't know how to handle register allocation and scheduling for this processor and pushing the problem onto the user? To put it another way, what happens with code that is not specially written for this processor? Ian
