> 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.
No, that's not how it works. We always support both the main
processor and the coprocessor at the same time, in the same
compilation, in the same function. The inlining keeps us from mixing
VLIW and non-VLIW mode at the same time, since VLIW mode has a wider
range (superset) of opcodes, so if you use a __builtin_* or asm() that
only works in VLIW mode, you can't inline it into a non-VLIW function
because those __builtin's or asm()'s won't work.
What you're suggesting is similar to having to move all i686 floating
point operations into a separate file from the integer operations.
> 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?
No, it's more like this:
typedef int copsi __attribute__((mode(COPSI)));
void foo (int *a, copsi *b, int i)
{
while (i--)
{
*a *= 2;
*b *= 2;
}
}
This will keep both the core multiplier and the coprocessor multiplier
busy.
Since both units run simultaneously, we need two sets of modes, one
for each unit, so the programmer can indicate which unit each
operation belongs on.
