Comment 5 for bug 903178

Ramana Radhakrishnan (ramana) wrote :

This is funny -

For Linaro 4.6 for the afflicted instruction we see :

Reload 0: reload_out (SI) = (reg/v:SI 208 [ Suppressed ])
 LO_REGS, RELOAD_OTHER (opnum = 0)
 reload_out_reg: (reg/v:SI 208 [ Suppressed ])
Reload 1: reload_in (SI) = (reg/v:SI 1356 [ OnMacroInst ])
 LO_REGS, RELOAD_FOR_INPUT (opnum = 1)
 reload_in_reg: (reg/v:SI 1356 [ OnMacroInst ])
Reload 2: reload_in (SI) = (reg/v:SI 1358 [ MacroSkipEnd ])
 LO_REGS, RELOAD_FOR_INPUT (opnum = 2)
 reload_in_reg: (reg/v:SI 1358 [ MacroSkipEnd ])
Reload 3: reload_in (SI) = (reg/v:SI 1356 [ OnMacroInst ])
 LO_REGS, RELOAD_FOR_INPUT (opnum = 4)
 reload_in_reg: (reg/v:SI 1356 [ OnMacroInst ])
Reload 4: reload_in (SI) = (reg/v:SI 1357 [ MacroSkipStart ])
 LO_REGS, RELOAD_FOR_INPUT (opnum = 5)
 reload_in_reg: (reg/v:SI 1357 [ MacroSkipStart ])
$19 = void

For FSF trunk we seem to start with a different set of reload classes :

<ramana> and for the same insn in FSF trunk I see
<ramana> Reload 0: reload_out (SI) = (reg/v:SI 181 [ Suppressed ])
<ramana> LO_REGS, RELOAD_OTHER (opnum = 0)
<ramana> reload_out_reg: (reg/v:SI 181 [ Suppressed ])
<ramana> Reload 1: reload_in (SI) = (reg/v:SI 1321 [ OnMacroInst ])
<ramana> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
<ramana> reload_in_reg: (reg/v:SI 1321 [ OnMacroInst ])
<ramana> Reload 2: reload_in (SI) = (reg/v:SI 1323 [ MacroSkipEnd ])
<ramana> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2)
<ramana> reload_in_reg: (reg/v:SI 1323 [ MacroSkipEnd ])
<ramana> Reload 3: reload_in (SI) = (reg/v:SI 1321 [ OnMacroInst ])
<ramana> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 4)
<ramana> reload_in_reg: (reg/v:SI 1321 [ OnMacroInst ])
<ramana> Reload 4: reload_in (SI) = (reg/v:SI 1322 [ MacroSkipStart ])
<ramana> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 5)
<ramana> reload_in_reg: (reg/v:SI 1322 [ MacroSkipStart ])
<ramana>

That looks fishy to me - rsandifo on IRC also pointed out to make sure we understand why FSF trunk thinks that the output reload should be in the LO_REGS . The only reason I can think of that is that we might prefer lo_regs there to allow the compiler to generate 16 bit encodings if possible but this is proving to be interesting.

cheers
Ramana