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


   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.


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