This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patches to reorg.c
- To: Haj dot Ten dot Brugge at net dot HCC dot nl (Herman ten Brugge)
- Subject: Re: patches to reorg.c
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 25 Jun 1998 01:13:38 -0600
- cc: gcc-patches at gnu dot org, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <353bba540.36a9@htbrug.net.HCC.nl>you write:
> The first problem is with steal_delay_list_from_target. If you have the
> following program:
> bned label : delayed branch to label when condition is not equal
> cmp 1,r0 : 3 delay slots the first one modifies the
> <empty> condition codes.
> <empty>
>
> label:
> bned anotherlabel
> cmp r2,r3 : another instruction that modifies the
> <empty> condition codes.
> <empty>
I'm a little suprised that we allowed an instruction which set the
condition codes in the delay slot of a conditional branch to start
with.
For machines that define HAVE_cc0 this should never happan as the
setter & user are required to remain consecutive and in-order.
For machines that do not define HAVE_cc0 I would think the existing
resource tracking code would avoid putting an instruction that sets
the condition codes into the delay slot of a conditional branch
Is that not the case? Can you explain more?
> The second problem is with try_merge_delay_insns. The following code shows
> the problem:
> bned label : delayed branch to label when condition is not equal
> ldiu r3,r0 : tree delay instructions which modify r0
> lsh -16,r0
> addi 1,r0,r0
>
> ldiu r3,r0 : some other code that modifies r0
> lsh -16,r0
> label:
> The problem was that the second 'ldiu r3,r0' was removed. This was because
> only the first instruction in the delayed branch was compared with this
> instruction. I now first set the mark_referenced_resources for all
> instructions in the delay list and then check if we can get rid of the
> extra instructions.
It's a little over conservative, but that's OK. Can you extract this
patch and send it seprately from the others?
> The third problem I had was also in this function. Sometimes some intructions
> were not copied into the delay list because the calls to mark_set_resources and
> mark_referenced_resources were missing. This happened in a large switch
> statement. The code is probably to big to include. If someone is interested
> I can mail the c and assembler source.
I'd like to see this as a separate patch with a little more information
about when we were missing calls. If you describe the problem well I
may not need the code itself.
jeff