Re: bin/47301: Miscompilation by bundled GCC

[<Paul_Koning%Dell.com@localhost>]

On Dec 10, 2012, at 9:22 AM, Torbjorn Granlund wrote:

> I looked a bit into this GCC problem, using gcc 4.7.2.
> 
> It seems to be a reload problem, and I think the vax port is innocent.
> 
> We have (slightly edited for legibility),
> 
>  (set (mem:SI (mem/f:SI (plus:SI (reg/v/f:SI 261 [ x ])
>                                 (const_int 8))))
>       (mem/u:SI (plus:SI (mult:SI (reg/v:SI 262 [ n ])
>                                  (const_int 4))
>                         (symbol_ref:SI ("__gmp_oddfac_table")))))
> 
> which then gets reloaded into,
> 
>  (set (reg:SI 1 %r1)
>       (mem/f/c:SI (plus:SI (reg/f:SI 12 %ap)
>                           (const_int 4))))
> 
>  (set (reg:SI 1 %r1)
>       (mem/c:SI (plus:SI (reg/f:SI 12 %ap)
>                         (const_int 8))))
> 
>  (set (mem:SI (mem/f:SI (plus:SI (reg:SI 1 %r1)
>                                 (const_int 8))))
>       (mem/u:SI (plus:SI (mult:SI (reg:SI 1 %r1)
>                                  (const_int 4))
>                         (symbol_ref:SI ("__gmp_oddfac_table")))))
> 
> i.e., reload puts both pseudo 261 and pseudo 262 into hard reg 1 in
> the same live range.  That is bad.
> 
> Very few current backends support mem-to-mem copying in a single
> instruction.  It might be something that no longer works in reload.
> 
> Assuming my assumption is correct, a possible fix would be to disallow
> mem-to-mem insns, at least until reload.
> 
> -- 
> Torbjörn

I wonder what that workaround would do to performance.  This sort of reload 
case could pop up in lots of machine architectures -- any CISC-like machine 
might be affected.  pdp11, 68k, i386, ...

        paul