Vladimir thanks for help! With respect to your answer I would like to point to you a possible way to solve the scheduling problem (which I think wont be too difficult to be implemented in genautomata).
To explain it, I will make use of the “move insn” example pointed in the previous email. First of all I do not change anything in the 2 automatons (aut1 and aut2); they are correctly built by the genautomata. Next to the original > (define_reservation "move" "( (unit1_aut1, unit1_aut2) | > (unit2_aut1, unit2_aut2) > ) I define two separate fake move instructions (i.e., “move_fake1” and “move_fake2”) of which semantic does play any role; each of them having a unit reservation one of the alternatives of the “move”: (define_reservation "move_fake1" "( (unit1_aut1, unit1_aut2)), and (define_reservation "move_fake2" "( (unit2_aut1, unit2_aut2) ). Those two extra moves are then used during the sched2 target hook TARGET_SCHED_DFA_NEW_CYCLE to decide which of the move alternative unit reservations can be correctly claimed. Suppose the ready instruction is a “move”. First I make 2 copies of the current state: temp_state1 and temp_state2. Then I check which of the two fake moves ( “move_fake1” and “move_fake2”) with different unit occupation can be issued at the current state: cost_move_fake1 = internal_state_transition (insn_code_move_fake1, temp_state1); cost_move_fake2 = internal_state_transition (insn_code_move_fake2, temp_state2); Once I find the correct choice (suppose cost_move_fake1 <0), I set dfa_insn_codes[] of the ready instruction to the one of move_fake1. int uid = INSN_UID (ready); if (uid >= dfa_insn_codes_length) dfa_insn_code_enlarge (uid); dfa_insn_codes[uid] = internal_dfa_insn_code (insn_code_move_fake1); In this way when the scheduler calls internal_state_transition, the ready instruction has been already set its dfa_insn_codes to a unit reservation schedulable in the current state. regards, Alex --- On Tue, 3/3/09, Vladimir Makarov <vmaka...@redhat.com> wrote: > From: Vladimir Makarov <vmaka...@redhat.com> > Subject: Re: query automaton > To: atur...@yahoo.com > Cc: gcc@gcc.gnu.org > Date: Tuesday, March 3, 2009, 4:35 PM > Alex Turjan wrote: > > 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? > > > > > Last two days, I've been working on this issue. I > found that you are right, genautomata permits to generate > incorrect automata although I did not find that it is a case > for major current description which I checked. > > I found the issue is complicated. Genuatomata has already > a check for correct automata generations in > check_regexp_units_distribution but that is not enough. I > am working on formulation of general rules for correct > automata generation and implementation of their check. I > think it will take a week or two to do this and check how > does it work for all current automata description. > > Alex, thanks for pointing out this issue to me.