I figured out that the insn_latency(insn1, insn2) is always returning a 
constant value in any states
(i.e., it's a static value, not be determined dynamically).
It seems to cost much time complexity if I impelemented the `nop inserting' in 
the reorg pass.
Because the `nop inserting' algorithm may be writtern as the following pseudo 
code:
   if(LOG_LINK(insn) is not empty) {
       foreach (dep_insn in LOG_LINK(insn)) {
           if(dep type is not true dependency) continue;
           stalls = insn_latency(dep_insn, insn);
           count =  the distance between insn and dep_insn;
           if(stalls > count) emit (stalls - count - 1) NOPs before insn;
       }
   }
The time complexity of this algorithm is O(n sqaure) and maybe highly 
increasing the compilation time.
Are there any better solution for the nop inserting?

Thanks a lot.

----- Original Message ----- From: "Richard Sandiford" <[EMAIL PROTECTED]>
To: "Ling-hua Tseng" <[EMAIL PROTECTED]>
Cc: <gcc@gcc.gnu.org>
Sent: Thursday, August 11, 2005 6:49 PM
Subject: Re: Question of the DFA scheduler


"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
The destination operand of the `sub' instruction, d0, will be written
back in the 4th cycle, and the instruction `max' will use it as source
operand (i.e., there is a true data dependency).

I figured out that the state_transition() returns -1 when I issuing
the `max' instruction, and I figured out it only returns > 0 when
"hardware structural hazard" occured.

Right.  state_transition just checks for unit hazards, not data hazards.

Instruction dependencies are detected by sched-deps.c and stored in the
instructions' LOG_LINKS.  insn_latency (in insn-attrtab.c) gives the
latency for two dependent instructions.

Richard

Reply via email to