[RFC/RFT] Should we hoist FP constants on x87?

[Jan Hubicka]

> On Wednesday 15 February 2006 17:05, Roger Sayle wrote:
> > On Wed, 15 Feb 2006, Uros Bizjak wrote:
> > > Roger, your patch brings ~1.2% speed improvements in povray benchmark:
> >
> > Wow!  Hopefully your POV-ray results are impressive enough to prompt
> > someone with SPEC to evaluate it on IA-32.  For the curious the original
> > patch proposal is at:
> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01859.html
> 
> I think you'd need to patch loop-invariant.c also, or it will hoist
> these constants because your patch doesn't cover loop-invariant.c.
> I'm not sure...  Did it even exist when you wrote it?  :-)
> 
> Anyway, untested, just a thought, and for your fun only.
> 
> Gr.
> Steven
> 
> 	* loop-invariant.c (constant_pool_constant_p): New local function.
> 	(get_inv_cost): Make hoisting constant pool loads into x87 registers
> 	very expensive in terms of register pressure.
> 
> Index: loop-invariant.c
> ===================================================================
> --- loop-invariant.c	(revision 111175)
> +++ loop-invariant.c	(working copy)
> @@ -604,6 +604,16 @@ may_assign_reg_p (rtx x)
>  	      || REGNO_REG_CLASS (REGNO (x)) != NO_REGS));
>  }
>  
> +#ifdef STACK_REGS
> +/* Check whether X is a constant pool constant.  */
> +static bool
> +constant_pool_constant_p (rtx x)
> +{
> +  x = avoid_constant_pool_reference (x);
> +  return GET_CODE (x) == CONST_DOUBLE;
> +}
> +#endif
> +
>  /* Finds definitions that may correspond to invariants in LOOP with body
>     BODY.  */
>  
> @@ -932,6 +942,32 @@ get_inv_cost (struct invariant *inv, int
>    (*regs_needed)++;
>    (*comp_cost) += inv->cost;
>  
> +#ifdef STACK_REGS
> +  {
> +    /* Hoisting constant pool constants into stack regs may cost more than
> +       just single register.  On x87, the balance is affected both by the
> +       small number of FP registers, and by its register stack organisation,
> +       that forces us to add compensation code in and around the loop to
> +       shuffle the operands to the top of stack before use, and po them from
> +       the stack after the loop finishes.
> +
> +       To model this effect, we increase the number of registers needed for
> +       stack registers by two: one register push, and one register pop.  This
> +       usually has the effect that FP constant loads from the constant pool
> +       are not moved out of the loop.
> +
> +       Note that this also means that dependent invariants can not be moved.
> +       However, the primary purpose of this pass is to move loop invariant
> +       address arithmetic out of loops, and address arithmetic that depends
> +       on floating point constants is unlikely to ever occur.  */
> +    rtx set = single_set (inv->insn);
> +    if (set
> +	&& IS_STACK_MODE (GET_MODE (SET_SRC (set)))
> +	&& constant_pool_constant_p (SET_SRC (set)))

You also want to test something like TARGET_SSE_MATH && SSE_FLOAT_MODE_P (...)
to not penalize SSE codegen.

Honza
> +      (*regs_needed) += 2;
> +  }
> +#endif
> +
>    EXECUTE_IF_SET_IN_BITMAP (inv->depends_on, 0, depno, bi)
>      {
>        dep = VEC_index (invariant_p, invariants, depno);