This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incorrect DFA scheduling of inline assembly
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Dan Towner <dant at picochip dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 31 Oct 2002 11:57:13 -0500
- Subject: Re: Incorrect DFA scheduling of inline assembly
- References: <3DC0FD5C.4000809@picochip.com>
Dan Towner wrote:
>
> Hi all,
>
> I am using the DFA scheduler for a 16-bit VLIW processor port. Some of
> my code contains inline assembler, and it appears that the scheduler is
> not allocating any resources to those instructions. This means that the
> inline assembly instructions are being incorrectly scheduled alongside
> other instructions:
>
> ;; ======================================================
> ;; -- basic block 7 from 62 to 147 -- after reload
> ;; ======================================================
>
> ;; 0--> 62 R6=R1 :slot0|slot1
> ;; 1--> 64 R5=asm_operands :nothing
> ;; 1--> 89 R6=R4|R3 :slot0|slot1
>
> ;; Ready list (final):
> ;; total time = 1
> ;; new head = 62
> ;; new tail = 89
>
> Notice that the asm_operands instructions, and the OR operation have
> both been scheduled into cycle 1, even though this should never happen -
> the asm instruction could use any number of VLIW slots.
>
> I would have thought that inline assembly instructions would have had
> the `unknown' attribute (i.e., the default for my attribute `type'),
> which would have meant that they used all the VLIW slots. Instead, they
> are somehow being scheduled so that they appear not to require any slots
> at all!
>
> Any ideas?
I'll look at this. It is not a serious bug for RISC processors which
have hardware interlocks. But it could be critical for VLIW
processors. I think the same bug exists when the old description is
used. The insn scheduler correctly issues the asm insn on new cycle.
But it should also issue any subsequent insn on the next cycle.
In any case it should be fixed in schedule_block of haifa-sched.c
Vlad