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.
This and the register changes come close to multi-arch gcc. Is that a direction we want to go? Historically we have not tried to support different architectures in the same compiler, even when there are coprocessors on the same chip. We've provided different compilers, and expected people to stich together the .o files. Do you have insns to move values from the main processor to and from the coprocessors? What do those insns look like? movcopsisi2? How do those insns get generated? > The CPU supports two operation modes - core and vliw. To properly > manage inlining, we need target hooks for when function A can inline > function B (both functions' attributes need to be inspected), and for > calls that are semantically disallowed (i.e. functions can't call > other-mode static inline functions). The core and vliw modes have > different instructions, and it's expected that users of this port will > make heavy use of intrinsics and asms, so even tree-level inlining > needs to be managed. Again my first reaction is whether it is necessary to compile code which runs in two completely different modes in the same compilation. If the functions can't call each other, why do they need to be compiled together? We have many ABI changing options which prohibit functions from calling each other, but that doesn't lead to any inlining problems. That said the machine independent changes here are presumably quite small. > We added a validate_replace_rtx_subexp() which is like > validate_replace_rtx() but only does the replacement on a > sub-expression of the insn. There's a chip-specific optimization that > uses this, we didn't want to have to recompute it ourselves. That seems trivial, no objection to that. Ian
