This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.2 vs 3.1 speed


"David S. Miller" wrote:

>    From: Vladimir Makarov <vmakarov@redhat.com>
>    Date: Wed, 05 Jun 2002 18:37:51 -0400
>
>    "David S. Miller" wrote:
>    > Or did you fix this?
>
>      Yes, it is fixed now.  Now only states of automata whose units are
>    used in the insn reservations are changed for given insn.
>
> And how do we determine which insn reservations apply to a given
> insn?  We have to make the "(eq_attr "cpu" "foo")" tests within the
> reservation at some point.
>
> I do not understand how DFA can avoid these tests since they are
> randomly mixed together with all the other tests within the
> reservation.
>
> For example, given:
>
> (define_insn_reservation "us1_single" 1
>   (and (eq_attr "cpu" "ultrasparc")
>     (eq_attr "type" "multi,flushw,iflush,trap"))
>   "us1_single_issue")
>
> (define_insn_reservation "us3_single" 1
>   (and (eq_attr "cpu" "ultrasparc3")
>     (eq_attr "type" "multi,flushw,iflush,trap"))
>   "us3_single_issue")
>
> How can DFA bypass the "cpu" check every single time it finds an insn
> which matches the "type" attribute test?
>
> Does the DFA machine mark "cpu" tests as special and perform them
> once at compiler startup after options are parsed?  That is the only
> way I can see that the problem could be fixed.

  There is a translation of insn into some internal insn(_reservaion) code
with the aid of standard genattrtab mechanism.  The same thing is used for
old description.   So there is no slow down in comparison with the old
description.  It is expansive, therefore there is also cache
INSN->internal code.  It may be wrong in rare cases because the value of
attribute tests may be depended on many things (e.g. short or long
branch).  But in overall advantage of the cache is bigger than its
disadvantage.  Although I should add a mechanism to switch off the cache.

  Genattrtab makes some optimizations in attribute evaluation.   I don't
remember how it behaves for cpu.  But I can guess it is evaluated every
time when the attribute value is needed.

Vlad



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]