> This is what we do for the Cell also, we expect people to compile > using two different compilers right now, but we are actually looking > into doing an "one source" based compiling where some functions or > loops are pushed off to the SPUs via annotations like the OpenMP > ones.
It sounds like we're not communicating properly. The total patch set to support core vs vliw modes, the part that needs to manage inlined functions by attribute, is a total of four lines of code in the core (not including prototypes). The two hooks are: /* Return true if function CALLER cannot call CALLEE. Report an error if so. CALLER is a decl and CALLEE is an arbitrary function expression. */ bool (* disallow_call_p) (tree caller, tree callee); /* Return true if function CALLER cannot inline calls to CALLEE. Both arguments are decls. */ bool (* disallow_inlining_p) (tree caller, tree callee); and their calls: if (targetm.disallow_inlining_p (node->decl, decl)) return false; if (targetm.disallow_call_p (current_function_decl, function)) return error_mark_node; That's it for the multi-mode code. The architecture is the same for both modes (registers, modes, ABI, etc). We just have to be careful about inlining one type of function into the other. The big part of the patch is support for coprocessor types, and in the MeP core, the coprocessor insns are in the same insn stream as the core insns (it's like an 80387 or mips fpu that way). The complication happens because there are more opcodes available in vliw mode than in core mode, but that's something that is private to the target-specific code. The MeP backend *does* support different chip configurations in different compilations via command line arguments and multilibs, but that's a complication on top of the ones I'm discussing, and the gcc core doesn't need to know about that (other than the usual ways).
