Re: query automaton

[Vladimir Makarov <vmakarov at redhat dot com>]

Alex Turjan wrote:
> Hello,
> Some time ago I asked a question regarding the possibility to schedule an operation on alternative functional units (FUs) AND depending on the chosen FUs to generate a dedicated assembly mnemonic. 
>
> To give a simple example suppose I have a move operation that can be issued on one of the 2 different FUs:
>
> (define_reservation "si_move""(q_salu, r_salu_rp,r_salu + r_salu_r_wp)
> 		           |(q_smac, nothing,  r_smac + r_smac_wp) 
> 			  ,nothing* 3") 
>
> Depending on the occupied FUs one of the following assembly instructions are generated: move_salu or move_smac.
>  
> To find out which FUs were occupied I defined 2 query_cpu_unit-s:
> (define_query_cpu_unit "q_salu"	 "aut1")
> (define_query_cpu_unit "q_smac"	 "aut1")
>
> ,which further on (during the sched2 hook TARGET_SCHED_DFA_NEW_CYCLE) are used to find out which of the 2 alternative reservations the automaton has taken. Based on this decision I add some information within the insn rtx which later on is used to dump "move_salu" or "move_smac".
>
> This approach was successful as long as the units claimed by "si_move" belong to one and the same automaton ( i.e., q_salu, q_smac, r_salu_rp, r_salu, r_salu_r_wp, r_smac, r_smac_wp belong to "aut1").
>
> If I try to split "aut1" into (lets say 2) automatons I get generated incorrect code (i.e., the choice of choosing the proper unit is not correct anymore.) 
>
> QUESTION: Is there such constraint that the units part of the alternatives of a reservation must belong to the same automaton?
>
>
>       
>   
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.  If 
it does not work, please send me a test case to reproduce the bug (if it 
is a bug).