Hi! On Sun, Jun 26, 2022 at 07:07:35PM +0200, Uros Bizjak via Gcc-patches wrote: > On Sun, Jun 26, 2022 at 2:04 PM Roger Sayle <ro...@nextmovesoftware.com> > wrote: > > I'll investigate whether this optimization can also be implemented > > more generically in simplify_rtx when the backend provides > > accurate rtx_costs for "(and (not ..." (as there's no optab for > > andn).
"Accurate rtx_cost" is a fallacy. insn_cost can be seen as somewhat accurate (in some simplified model of reality), but rtx_cost always misses too much context to be useful as anything but a rough estimate. > *combine splitter is described in the documentation as the splitter > pattern that does *not* match any existing insn pattern. Yeah, that documentation is somewhat misleading, in both directions :-( combine can and will and does use any splitter, whether or not there is an insn with that insn pattern. If there is an insn that passes recog() combine will not even try a split, but this is not the same thing at all: if the insn conditions are not met, the insn does not recog(). It is quite common to have the same instruction pattern with different insn conditions. In the other direction, other passes can call split_insns as well, of course. Nothing currently does, but that does not change much :-) Segher
