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: query automaton


Dear Vladimir,     
> Not really.  There is no requirement for "the units
> part of the alternatives of a reservation must belong to the
> same automaton".  Querying should also work in this
> case because function cpu_unit_reservation_p checks all
> automata for an unit reservation. 
Indeed it checks all automata but Im afraid that according to my pipeline description this check is not enough to guarantee a correct scheduling decision, e.g.,
suppose the following insn reservation: 

(define_reservation "move"  "(  (unit1_aut1, unit1_aut2) |              (*)
                                (unit2_aut1, unit2_aut2)  ) 

,where unitN_autM refers to unit N from automata M. In this case there are 2 automata. 
Now supose a scheduling state S made of the individual states of the two automatons S=<S_aut1,S_aut2>. According to what I see happening in insn-automata.c (and target.dfa), from S_aut1 there is a transition for unit1_aut1 and from S_aut2 there is a transition for unit2_aut2. 

It seems that the automata do not communicate with each other. As a consequence, 
A scheduling decision which results in the resource reservation  
(unit1_aut1, unit2_aut2)  would not be rejected, while it should. 
 
In my opinion, the current implementation sees the reservation defined in (*)
As equivalent to the following one
(define_reservation "move"  "(  (unit1_aut1| unit2_aut1) ,
                                (unit1_aut2| unit2_aut2)  ) 
Which does not seem  true to me. 

Is there a way for automatons to communicate so that the alternative 
(unit1_aut1, unit2_aut2) would be rejected?

regards,
Alex











      


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