[Bug target/70568] [4.9/5/6/7 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

pthaugen at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Jul 19 22:15:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568

--- Comment #4 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
(In reply to acsawdey from comment #3)
> Tracked this back to 210824, and in particular this change:
> 
> @@ -860,10 +897,15 @@
>                         }
>                     }
> 
> -                 /* If the alternative actually allows memory, make
> -                    things a bit cheaper since we won't need an extra
> -                    insn to load it.  */
> -                 if (op_class != NO_REGS)
> +                 if (op_class == NO_REGS)
> +                   /* Although we don't need insn to reload from
> +                      memory, still accessing memory is usually more
> +                      expensive than a register.  */
> +                   pp->mem_cost = frequency;
> +                 else
> +                   /* If the alternative actually allows memory, make
> +                      things a bit cheaper since we won't need an
> +                      extra insn to load it.  */
>                     pp->mem_cost
>                       = ((out_p ? ira_memory_move_cost[mode][op_class][0] :
> 0)
>                          + (in_p ? ira_memory_move_cost[mode][op_class][1] :
> 0)

So looking into things, there are the following 2 insns using pseudo 157:

(insn 2 4 3 2 (set (reg/v:SF 157 [ d ])
        (reg:SF 33 1 [ d ])) test.c:9 466 {movsf_hardfloat}
     (expr_list:REG_DEAD (reg:SF 33 1 [ d ])
        (expr_list:REG_EQUIV (mem/c:SF (plus:DI (reg/f:DI 67 ap)
                    (const_int 48 [0x30])) [1 d+0 S4 A64])
            (nil))))
(insn 11 6 12 2 (set (reg/i:DI 3 3)
        (sign_extend:DI (subreg:SI (reg/v:SF 157 [ d ]) 0))) test.c:16 40
{extendsidi2}
     (expr_list:REG_DEAD (reg/v:SF 157 [ d ])
        (nil)))

For the alternatives of the 2 insns that accept memory, the new code is now
setting a mem_cost of 1000 (frequency), whereas before it wouldn't have been
modified for those alternatives. This seems to ignore the fact that the given
insn alternatives will be a store and load.

Vlad,
  Should the new code somehow be taking into account memory_move_cost (i.e.
memory_move_cost * frequency)?


More information about the Gcc-bugs mailing list