> I don't think this is the way to go. AIUI the problem here isn't that > RISC architectures don't have QImode adds as such. If we were going > to combine insn 6 and insn 7 _in isolation_ then we would have either: > > (zero_extend:SI (subreg:QI (plus:SI (subreg:QI (reg:SI R)) > (const_int X)))) > > before the patch or: > > (zero_extend:SI (plus:QI (reg:QI R) > (const_int X))) > > after the patch. And IMO the second form is a simplification over the > first. (Despite being a RISC port, MIPS Octeon does have a pattern for > zero-extending byte addition, so this isn't entirely academic.)
Well, if you look at the transformation in isolation, you cannot reasonably say that it's a simplification for most RISC architectures either. That it happens to help zero-extensions on MIPS is fine, but it pessimizes other cases on other architectures (and maybe on MIPS as well). > It sounds like the problem is instead that we're relying on combine > to remove redundant zero extensions and that combine's no longer able > to do that when folding insns 6 and 7 into the comparison. Is that right? > I think it would better to use a dedicated global pass to remove redundant > extensions instead. IIRC there were various attempts to do that. The regressions affect 4.8 and mainline and it's probably too late to add new passes in order to mitigate them. > IMO combine should just be about instruction selection. The patch > still seems good to me from that POV. The patch is in simplify-rtx.c though, not in combine.c, so it's more general. -- Eric Botcazou
