http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195



Vladimir Makarov <vmakarov at redhat dot com> changed:



           What    |Removed                     |Added

----------------------------------------------------------------------------

                 CC|                            |vmakarov at redhat dot com



--- Comment #4 from Vladimir Makarov <vmakarov at redhat dot com> 2013-02-07 
19:24:58 UTC ---

(In reply to comment #3)

> I'd say the bug is in get_reload_reg.

> Changing pseudo 118 in operand 0 of insn 90 on equiv 0

> Changing address in insn 90 r59:DI -- no change

> Changing pseudo 59 in address of insn 90 on equiv 0

>       Creating newreg=137, assigning class GENERAL_REGS to address r137

>          Choosing alt 1 in insn 90:  (0) r  (1) rm

>          Reuse r137 for reload 0, change to class INDEX_REGS for r137

>    90: flags:CCGC=cmp(r137:DI,[r137:DI])

>     Inserting insn reload before:

>   256: r137:DI=0

> 

> 

> 3065          if (get_reload_reg (type, mode, old, goal_alt[i], "", &new_reg)

> 3066              && type != OP_OUT)

> 

> calls it with

> type=OP_IN, mode=SImode, original=const0_rtx, rclass=GENERAL_REGS

> but returns new_reg = (reg:DI 137).

> That is because:

>       if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

>           && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

> doesn't check any mode if original (and curr_insn_input_reloads[i].input) are

> VOIDmode as in this case.  So, either this can be fixed by doing:

>        if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

> -      && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

> +      && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class)

> +      && GET_MODE (curr_insn_input_reloads[i].reg) == mode)

> , or we could try better, if the GET_MODE (curr_insn_input_reloads[i].reg)

> is wider than mode, see if we can create a lowpart subreg thereof and return

> that, and only give up (i.e. continue looping) if creation of the lowpart

> subreg for some reason failed.

> 

> Vlad, what do you think?



I think, the second solution with lowpart is better.



Would you like to make a patch or may be you prefer that I work on it?

Reply via email to