On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote: > On 11/13/19 5:16 PM, Segher Boessenkool wrote: > > On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote: > >> Also, it does not compute costs for jump > >> insns, so they are always set to zero. As a consequence, any possible > >> substitution is performed if a combination into a jump is possible, > >> which turns out isn't really desirable on m68k with cbranch patterns. > >> > >> This patch simply removes a test for NONJUMP_INSN_P. Bootstrapped and > >> tested on the gcc135 machine (powerpc64le-unknown-linux-gnu). > > > > I wonder why that test was there. It was added in r84513, which is where > > insn_rtx_cost was made from combine_insn_cost, which didn't have that > > non-jump thing yet. > > > > It is still stage 1, so we'll find out if any target breaks I guess. > > Okay for trunk. Thanks! > > Thanks. Just FYI, this is held up a little. I decided I'd also test on > x86, and there it shows a case where ix86_rtx_cost misses something: the > i386/pr30315.c testcase wants to combine compares into addition+jump on > carry, but the rtx_costs show too high a cost for (compare (plus)). I'm > testing a fix for that in i386.c.
Maybe i386 should implement the insn_cost hook as well? For most targets that is a lot simpler to get right than rtx_cost, but allowing memory in many insns and all the different insn lengths complicates matters. At least insn_cost isn't inside-out, that should make it easier to deal with already. Segher
