> The comment says that we're trying to match: > > 1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int)))) > 2. (set (reg:QI) (plus:QI (mem:QI) (const_int))) > 3. (set (reg:QI) (plus:QI (subreg:QI) (const_int))) > 4. (set (reg:CC) (compare:CC (subreg:QI) (const_int))) > 5. (set (reg:CC) (compare:CC (plus:QI (mem:QI) (const_int)))) > 6. (set (reg:SI) (leu:SI (subreg:QI) (const_int))) > 7. (set (reg:SI) (leu:SI (subreg:QI) (const_int))) > 8. (set (reg:SI) (leu:SI (plus:QI ...))) > > And I think that's what we should be matching in cases where the > extension isn't redundant, even on RISC targets.
Which one(s) exactly? Most of the RISC targets we have are parameterized (WORD_REGISTER_OPERATIONS, PROMOTE_MODE, etc) to avoid operations in modes smaller than the word mode. > The problem here isn't really about which mode is on the plus, > but whether we recognise that the extension instruction is redundant. > I.e. we start with: > > (insn 9 8 10 2 (set (reg:SI 120) > (plus:SI (subreg:SI (reg:QI 118) 0) > (const_int -48 [0xffffffffffffffd0]))) test.c:6 -1 > (nil)) > (insn 10 9 11 2 (set (reg:SI 121) > (and:SI (reg:SI 120) > (const_int 255 [0xff]))) test.c:6 -1 > (nil)) > (insn 11 10 12 2 (set (reg:CC 100 cc) > (compare:CC (reg:SI 121) > (const_int 9 [0x9]))) test.c:6 -1 > (nil)) > > and what we want combine to do is to recognise that insn 10 is redundant > and reduce the sequence to: > > (insn 9 8 10 2 (set (reg:SI 120) > (plus:SI (subreg:SI (reg:QI 118) 0) > (const_int -48 [0xffffffffffffffd0]))) test.c:6 -1 > (nil)) > (insn 11 10 12 2 (set (reg:CC 100 cc) > (compare:CC (reg:SI 120) > (const_int 9 [0x9]))) test.c:6 -1 > (nil)) > > But insn 11 is redundant on all targets, not just RISC ones. > It isn't about whether the target has a QImode addition or not. That's theoritical though since, on x86 for example, the redundant instruction isn't even generated because of the QImode addition... > Well, I think making the simplify-rtx code conditional on the target > would be the wrong way to go. If we really can't live with it being > unconditional then I think we should revert it. But like I say I think > it would be better to make combine recognise the redundancy even with > the new form. (Or as I say, longer term, not to rely on combine to > eliminate redundant extensions.) But I don't have time to do that myself... It helps x86 so we won't revert it. My fear is that we'll need to add code in other places to RISCify back the result of this "simplification". -- Eric Botcazou
