DJ Delorie <[EMAIL PROTECTED]> writes: > > Coprocessor types - the MeP chip has optional coprocessors, each with > > their own register sets. They need their own internal types (mostly > > to keep track of which unit to use), which we've created by prefixing > > the existing types with COP (i.e. COPSImode, COPDFmode, etc). This > > affects the generators, some MI files, etc. The types don't exist > > unless the target calls for them. > > Here's the first pass at this portion of the patch, originally written > by Richard over three years ago. No regressions on i686-linux.
It's hard for me to be happy with a patch like this. As far as I can see you're using new modes to drive register class preferences. This isn't done in a general way: you've simply permitted doubling the standard modes. It's not immediately obvious how you get values in the new modes. Presumably there is something processor specific that generates them. The code itself is not general even within these constraints: e.g., the change to find_reloads_toplev. And there is no documentation. Earlier you sent out a patch preventing inlining. That suggests that you can not compile code to run on both the main processor and the coprocessor at the same time. If that is correct, then why do you need these coprocessor modes? For example, why can't you set the mode in struct machine_function and check that when recognizing insns? Ian
