This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Describe more Sparc RTX costs
- From: Jan Hubicka <jh at suse dot cz>
- To: "David S. Miller" <davem at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 5 May 2002 11:19:47 +0200
- Subject: Re: Describe more Sparc RTX costs
- References: <20020505.004418.21595206.davem@redhat.com>
>
> 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