On 10/22/20 4:24 PM, Segher Boessenkool wrote: > 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 ;-) ) I'd bet on the predicates and the insn condition. I wouldn't be surprised at all if this is a risc-like architecture where only one operand can be a non-register. Predicates can't really describe that, so it's usually handled in the insn predicate. jeff > > > Segher >
