In http://gcc.gnu.org/ml/gcc/2007-03/msg01007.html, Steven Bosscher wrote: > All of this feels (to me anyway) like adding a lot of code to the > middle end to support MEP specific arch features. I understand it is > in the mission statement that more ports is a goal for GCC, but I > wonder if this set of changes is worth the maintenance burden...
The ARC also has an optional SIMD coprocessor, for which it would be useful to be able to specify that specific oprtations should be done on the coprocessor. Moreover, our current register class preferencing and mode tying heuristics are somewhat weak, and next-to-useless in the first scheduling pass; if we'll have specific modes for computations on the coprocessor, I think it will be easier for the compiler to automatically make sure that computations that feed into or depend on other computations on the coprocessor are also done on the coprocessor. This could even help more traditional processors. I remember for SHmedia, the floating point registers can hold integer values, but when you tell the compiler the facts straight as in cost of moves between various register classes, you'll end up with lots of moves of integer values between integer and floating point registers. You actually have to fiddle the cost to pretend that movsi_media alternatives involving only floating point registers are more costly than they actually are to avoid this pessimization. I suppose a similar scenario might be true for integer operations in floating point registers on x86 with MMX and its successors. Using separate modes for integer computations in floating point registers on these processors could help gcc to model the cost of transferring values between integer and floating point units. It also can make TRULY_NOOP_CONVERSION more relevant, as the answer is often different between integer and floating point registers.
