https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to liwei from comment #3)
> Thank you for your quick reply!
>
> The final call of the expand_simple_binop function returns part of the code
> as follows (optabs.cc):
>
> 1671 xop0 = widen_operand (xop0, wider_mode, mode, unsignedp, no_extend);
> 1672
> 1673 /* The second operand of a shift must always be extended. */
> 1674 xop1 = widen_operand (xop1, wider_mode, mode, unsignedp,
> 1675 no_extend && binoptab != ashl_optab);
> 1676
> 1677 temp = expand_binop (wider_mode, binoptab, xop0, xop1, NULL_RTX,
> 1678 unsignedp, OPTAB_DIRECT);
> 1679 if (temp)
> 1680 {
> 1681 if (mclass != MODE_INT
> 1682 || !TRULY_NOOP_TRUNCATION_MODES_P (mode, wider_mode))
> 1683 {
> 1684 if (target == 0)
> 1685 target = gen_reg_rtx (mode);
> 1686 convert_move (target, temp, 0);
> 1687 return target;
> 1688 }
> 1689 else
> 1690 return gen_lowpart (mode, temp);
> 1691 }
>
> In the above code, target = result, when promote xop0 and xop1 machine mode
> to DI, then match adddi3 insn pattern and save the new rtx to temp, then
> because the mclass equal MODE_INT (also equal true for
> TRULY_NOOP_TRUNCATION_MODES_P function), the code enter else branch and
> return lowpart of temp which is irrelevant with target (i.e. result).
Sure, but expand_simple_binop doesn't need to return 'target'
> Maybe the expand_binop function does not consider the case of dependency
> with `target` when generating rtx for the case of promote MODE_INT mode, and
> maybe theoretically it does not need to be considered, except that
> builtin_strcmp happens to meet such cases, so I think it is enough to modify
> the processing logic of builtin_strcmp (my humble opinion).
I'm still missing the obvious? We assign the result to 'result', so it
should be all fine? I see that emit_cmp_and_jump_insns eventually forces
the lowpart to a register but still it should work.
