This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Check rtx_costs in combine.c's try_combine
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: roger at eyesopen dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Jun 04 13:45:43 EDT
- Subject: Re: [PATCH] Check rtx_costs in combine.c's try_combine
Clearly this instruction should never be used where ever a synthetic
multiply sequence of shifts and adds is cheaper.
And indeed it won't be now, so I don't understand the relevance of this.
Your proposal would seem to imply that we duplicate the entire cost
logic of synth_mult into each backends expander for multiply patterns,
so that they can themselves FAIL if there potentially exists a better
replacement.
Well, actually the other approach would for them to *call* the synth_mult
logic, though I agree that it would be a bit extreme.
However it is still cheaper than variable multiplications, such as
"imul %ebx, %eax", hence should CSE, GCSE or reload manage to
determine that the value of %ebx is always 4, we'd be deteriorating
the quality of code we produce, as the GCC backends provide no
mechanism when they fail to match a pattern to describe the
replacement sequence that should be used instead.
Well, they sort of do but not in this sort of instruction case and it
wouldn't be used by those passes anyway. SO I accept this.
It would probably break the compiler to reject patterns for particular
operand values (though certainly deteriorate code quality). For
example, the middle-end's expand_shift currently doesn't have a way of
falling back to using additions if using the ashl_optab fails, hence a
backend that fails to recognize shifts-by-two in an attempt to get the
compiler to generate two additions, is shooting itself in the foot,
and may even end up generating calls to ashlsi3 in libgcc!
True.
There are have been plenty of bugs in the RTL optimizers, where we'd
fail to re-recognize and instruction after making a change. Most of
these have been fixed.
I would hope so. I haven't seen any of those in a long time, and few ever
since validate_change was added a very long time ago.
But its commonly, the case that the RTL optimizers assume they don't
need to rerecognize an instruction when replacing a pseudo with a
constant, or one constant with another.
Certainly not true! Nearly all RISC machines have limits on the sizes of
operands. This sort of checking is the most important of all.
All of GCSE for example.
Perhaps there are some bugs, but most RISC machines have restrictions
on the ranges of constants for most operands and we don't run into that
many problems.
Adding constraints on operand values will open up a whole can of worms
with "unrecognizable insn" and "insn doesn't satisfy it's constraint" ICEs.
But, as I say, the vast majority of machines *already have them*!