This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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*!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]