Re: patches to reorg.c for c4x

[Jeffrey A Law <law at cygnus dot com>]

  In message <199809291822.TAA12533@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>
  > 
  > The problem I was having is that the instruction 'cmp 1,r0' modifies the
  > condition codes. We can not steal any instructions from the delay list
  > if any of the instructions modify the condition codes. This test is only
  > needed if we try to steal instructions from conditional branches.
My first question is how did we end up with an insn which sets CC0 in a delay
slot?  I think that is the real root of the problem -- I do not think that
should be happening.

I suspect there's something funny going on in the c4x backend which is leading
to this problem.  The conditional branch should (effectively) use the cc0 reg,
which should in turn prevent an insn which sets the cc0 reg from being placed
in its delay slot.  Right?



  > 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 equ
  > al
  >           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.
This patch is OK and installed it.  Note that you need to make sure to include
ChangeLog entries for each specific change in the future.

  > The third problem I had was also in this function. The sequence below
  > shows the problem.
  > 
  >         label:
  > 	 ... 		some other code
  > 
  >          bgtd label     : delayed branch to label when condition is greater
  >  then
  >           cmpi3  0,r4   : set condition codes
  >           nop
  >           nop
  > 	 bd label	: unconditional delayed branch to label
  > 	  addf   f7,*ar0,r0 : add and destroy condition codes
  > 	  stf    f0,*ar0    : store result
  >           cmpi3  0,r4   : set condition codes
  > 
  > The problem was that the second 'cmpi3 0,r4' was removed because the 
  > resources were not updated. The patch below fixes this.
I installed this patch too.

  > The patch below is allready included in testgcc-980813. I modified the 
  > routine check_annul_list_true_false the same way as was suggested by
  > Paul Eggert <eggert@twinsun.com> on Mon Aug 17 00:12:42 1998.
I installed this patch too.

Thanks,
jeff