This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patches to reorg.c



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]