Re: shift_cost et al

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 10 Jul 2004, Richard Henderson wrote:
> What we're doing is generating some random rtl, trying to recognize it,
> and if we get a match then we accept the result of rtx_cost.
>
> I'm of a mind to simply take the call to recog out.  If the rtx_cost
> hook for the target is written well, then the shiftadd/shiftsub bits
> will be handled correctly.  And the rest can be fixed.
>
> Thoughts?

Sounds reasonable.  These calls to recog date back to 1993, but I think
that the quality of TARGET_RTX_COSTS have come a long way since then.

With this change, init_expmed can be cleaned up even further: there's
no need to call init_recog (unless some other code is incorrectly
relying on it), then we don't have to call emit_insn for the
shift_insn, shiftadd_insn and shiftsub_insn as its only the SHIFT/PLUS
RTX that we care about.  This avoids calls to gen_rtx_SET, extracting
patterns for shift_pat et al., and all the dinking through SET_SRC.
I think we can also get rid of start_sequence() and end_sequence().


My only worry is that we'll need to check the various rtx_costs
implementations.  Many backends incorrectly assume that they're only
ever passed "recognized" RTL, so often check for a top-level PLUS
and return true, which won't account for a shift/multiplication
operand.  These problematic backends should be easy enough to fix.

Roger
--