--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 07:57
---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
- cannot support. An exception is a CONSTRUCTOR into a multi-word
- MEM: that's much more likely to be most efficient into the MEM.
- Another is a CALL_EXPR which must return in memory. */
So it looks like point 2 is true.
Except that CSE has not been run yet. :-)
The problem is that the ashrdi3 expander is not matched by existing insns in
the (MEM, MEM, CONST_INT) case. Either the predicates need to be tightened
or one of the operands needs to be forced to a register in the preparation
statements.
While you're at it, please delete the 3 bogus comments added by Jeff as part
of revision 24814:
(define_expand ashrdi3
[(set (match_operand:DI 0 nonimmediate_operand )
(ashiftrt:DI (match_operand:DI 1 general_operand )
(match_operand 2 const_int_operand )))]
!TARGET_COLDFIRE
{
/* ??? This is a named pattern like this is not allowed to FAIL based
on its operands. */
if (GET_CODE (operands[2]) != CONST_INT
|| ((INTVAL (operands[2]) 1 || INTVAL (operands[2]) 3)
INTVAL (operands[2]) != 8 INTVAL (operands[2]) != 16
(INTVAL (operands[2]) 31 || INTVAL (operands[2]) 63)))
FAIL;
} )
Of course expanders are allowed to fail in the preparation statements based
on their operands, that's precisely why FAIL exists! See the example in the
13.15 section of the internals manual.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
Component|rtl-optimization|target
GCC host triplet|m68k-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
