On 04/08/2015 03:33 PM, Segher Boessenkool wrote:
PR65693 exposes a case where combine does a worse job after my patches to split parallels before combining. We start with a parallel of an udiv and an umod, and a clobber; the umod is dead. The instruction is combined with one setting the divisor pseudo to a power-of-two constant, so we end up with a parallel of an lshiftrt, an and (dead), and a clobber. This is not a recognised instruction.Before my patches this was a 2->1 combination, and the combiner throws away the dead set and everyone is happy. After the patches, this now is a 3->1 combination, the combiner does not throw away the dead set but tries to split the parallel into two, which does not work because one of the resulting insns has to end up as i2, which is earlier than the original sets. The combiner gives up. There already is code to throw away dead sets in the 3->1 case, but it only works for a parallel for two sets without any clobbers. This patch fixes it. Tested on powerpc64-linux (-m32,-m32/-mpowerpc64,-m64,-m64/-mlra); no regressions. Tested a cross to x86_64-linux on the PR65693 testcase, and it fixes it. Is this okay for current trunk? Segher 2015-04-08 Segher Boessenkool <seg...@kernel.crashing.org> * combine.c (is_parallel_of_n_reg_sets): Change first argument from an rtx_insn * to an rtx. (try_combine): Adjust both callers. Use it once more.
OK. jeff
