On 3/27/07, DJ Delorie <[EMAIL PROTECTED]> wrote:
* postreload.c (reload_cse_move2add): Don't look for strict lowparts
of coprocessor modes.
This changes is not in your patch.
* c-typeck.c (convert_for_assignment): Don't relax reference check.
And neither is this one.
You have machine modes for a co-processor. Somehow that doesn't feel
right to me. What if there comes a new architecture with two different
kind of co-processors? Will we have COPRO2_MODE_P/copro2_modes/etc.?
Also:
* expmed.c (expand_mult): If the variable operand is a coprocessor
value, use a coprocessor accumulator.
Why? Isn't this an architecture specific decision to make? Iff this
will ever be useful to other architectures than MEP (which I seriously
doubt), it could be better for that arch to use a normal mode.
So shouldn't this change be guarded by some kind of kost or
profitability checks, etc.?
Likewise for all other places where you appear to just take a
coprocessor mode if it is available.
- && reg_equiv_constant[regno] != 0)
+ && reg_equiv_constant[regno] != 0
+ /* Symbolic constants have no representation in coprocessor
+ modes. Just handle known constants. */
+ && (!COPRO_MODE_P (GET_MODE (x))
+ || GET_CODE (reg_equiv_constant[regno]) == CONST_INT
+ || GET_CODE (reg_equiv_constant[regno]) == CONST_DOUBLE))
Architecture specific?
Also, documentation is missing of the new coprocessor modes, and what
one is allowed to use them for and do with them.
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...
Gr.
Steven
