On Mon, Jun 17, 2019 at 04:47:29PM +0000, Joel Hutton wrote: > Hi Segher, > > > If you want the const_vector for r97, you should look at the combination > > that tries *that* insn together with 10 and 12. Did it try that? > Why not? > > It did not attempt to combine all three, I'm not sure why not, I would > have expected > it to, they are all in the same basic block.
I'll need some compilable source code to investigate this. That means compilable for *me*, so with some target that is in trunk. > I don't understand why in the other example > two insns were combined using a constant set by a third insn, but in > this case three > insns must be combined, perhaps because in this example they are in the > same basic block and in the other example the constant is set outside > the basic block? In this case you are *not* combining three insns: you would be "combining" *one* instruction. It would be changing it to try to set its destination reg to what is said in the REG_EQUIV some other way than using the insns that set it currently. And combine can already do that, when it tries to combine at least two of the insns. > insn_cost 4 for 33: r100:DI=x0:DI > REG_DEAD x0:DI > insn_cost 4 for 2: r94:DI=r100:DI > REG_DEAD r100:DI > insn_cost 4 for 34: r101:DI=x1:DI > REG_DEAD x1:DI > insn_cost 4 for 3: r95:DI=r101:DI > REG_DEAD r101:DI > insn_cost 4 for 5: r91:DI=0 > insn_cost 4 for 10: r98:V4SF=const_vector > insn_cost 8 for 9: r96:V4SF=[r94:DI+r91:DI] > insn_cost 8 for 11: r97:V4SF=r96:V4SF*r98:V4SF > REG_DEAD r96:V4SF > REG_EQUAL r96:V4SF*const_vector So this insn 5 makes it hard to combine with insn 9, because you'll quickly need a four insn combination, and those are restricted somewhat. But 10+11 should do something. But it seems it isn't tried at all? Huh. Segher
