Re: Describe more Sparc RTX costs

[Jan Hubicka <jh at suse dot cz>]

> 
> This enhances sparc_rtx_costs as I intended to do so yesterday.
> Now that the big RTX_COSTS macro was split out into sparc.c this
> was easy to do :-)
> 
> Basically the latencies as known by the various DFA schedulers was
> transformed into RTX costs.  I added a note to the top of this
> function that genautomata should eventually do this kind of busy
> work for us :-)
> 
> 2002-05-05  David S. Miller  <davem@redhat.com>
> 
> 	* config/sparc/sparc.c (sparc_rtx_costs): Describe costs of
> 	more RTX codes.
> 	* config/sparc/sparc.h (RTX_COSTS_CASES): List those new codes.
> 
> --- config/sparc/sparc.c.~1~	Fri May  3 22:27:55 2002
> +++ config/sparc/sparc.c	Sun May  5 00:00:15 2002
> @@ -8086,6 +8086,10 @@ sparc_extra_constraint_check (op, c, str
>    return reload_ok_mem;
>  }
>  
> +/* ??? This duplicates information provided to the compiler by the
> +   ??? scheduler description.  Some day, teach genautomata to output
> +   ??? the latencies and then CSE will just use that.  */

This sounds like neat, but tricky idea, as it is dificult to track down
what pattern will be used.
> +    case SQRT:
> +    case COMPARE:
> +    case IF_THEN_ELSE:

Is there somme benefit from modeling instructions like this ones?
I think there is no use for it in the compiler, but in case I am
mistaken, I will add similar code to the i386 backend.
> +    case MEM:
> +      /* If outer-code is SIGN/ZERO extension we have to subtract
> +	 out COSTS_N_INSNS (1) from whatever we return in determining
> +	 the cost.  */
> +      switch (sparc_cpu)

Should not we just default to address cost here?

Honza