On Thu, Oct 22, 2020 at 03:30:08PM -0600, Jeff Law via Gcc-help wrote: > On 10/22/20 2:02 AM, Henri Cloetens wrote: > > Motivation for the split was problems with the "combine" step. Suppose > > following code: > > *a = 10. > > Even if my front_end (define_expand) splits this in > > r100 = 10 > > *r101 = r100 > > the combine step, if these is only one movesi_internal, willl group > > it again, to then find out > > there is no instruction pattern. > > This is an indication the insn's condition or operand's predicate or > operand constraints are wrong. Yes, but I do not understand what Henri means at all. On one side, combine will try to combine any such pair, and then it does discover there is no insn for that, and then not do the combination. This is exactly what combine is supposed to do. On the other side, it could mean combine *does* allow the combo. Then, you *do* have a define_insn for it, or it would *not* allow it. And then some time later that is a problem? But that has nothing to do with combine, that just is a buggy machine description. (My money is on the predicate btw ;-) ) Segher
