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: Is http://www.cygnus.com/ml/egcs-bugs/1998-Jul/0147.html fixed


>   > It dies on me too. I just want to make sure I didn't do anything wrong.
>   > Here is a patch. The problem is the register on the stack reg-stack.c
>   > is virtual. That is why we have get_hard_regnum () to get the hard
>   > register number from the virtual register.
> You didn't explain the bug or anything about how your patch fixes
> the bug.  Thus it was ignored.  I've got more important things to
> do than pester you for critical information.
> 

That is ridiculous. I provided enough information for anyone who has
worked on reg-stack.c to understand what is going on. Here is the
comment in reg-stack.c from line 21 to line 82:

/* This pass converts stack-like registers from the "flat register
   file" model that gcc uses, to a stack convention that the 387 uses.

   * The form of the input:

   On input, the function consists of insn that have had their
   registers fully allocated to a set of "virtual" registers.  Note that
   the word "virtual" is used differently here than elsewhere in gcc: for
   each virtual stack reg, there is a hard reg, but the mapping between
   them is not known until this pass is run.  On output, hard register
   numbers have been substituted, and various pop and exchange insns have
   been emitted.  The hard register numbers and the virtual register
   numbers completely overlap - before this pass, all stack register
   numbers are virtual, and afterward they are all hard.

   The virtual registers can be manipulated normally by gcc, and their
   semantics are the same as for normal registers.  After the hard
   register numbers are substituted, the semantics of an insn containing
   stack-like regs are not the same as for an insn with normal regs: for
   instance, it is not safe to delete an insn that appears to be a no-op
   move.  In general, no insn containing hard regs should be changed
   after this pass is done.

   * The form of the output:

   After this pass, hard register numbers represent the distance from
   the current top of stack to the desired register.  A reference to
   FIRST_STACK_REG references the top of stack, FIRST_STACK_REG + 1,
   represents the register just below that, and so forth.  Also, REG_DEAD
   notes indicate whether or not a stack register should be popped.

   A "swap" insn looks like a parallel of two patterns, where each
   pattern is a SET: one sets A to B, the other B to A.

   A "push" or "load" insn is a SET whose SET_DEST is FIRST_STACK_REG
   and whose SET_DEST is REG or MEM.  Any other SET_DEST, such as PLUS,
   will replace the existing stack top, not push a new value.

   A store insn is a SET whose SET_DEST is FIRST_STACK_REG, and whose
   SET_SRC is REG or MEM.

   The case where the SET_SRC and SET_DEST are both FIRST_STACK_REG
   appears ambiguous.  As a special case, the presence of a REG_DEAD note
   for FIRST_STACK_REG differentiates between a load insn and a pop.

   If a REG_DEAD is present, the insn represents a "pop" that discards
   the top of the register stack.  If there is no REG_DEAD note, then the
   insn represents a "dup" or a push of the current top of stack onto the
   stack.

   * Methodology:

   Existing REG_DEAD and REG_UNUSED notes for stack registers are
   deleted and recreated from scratch.  REG_DEAD is never created for a
   SET_DEST, only REG_UNUSED.

   Before life analysis, the mode of each insn is set based on whether
   or not any stack registers are mentioned within that insn.  VOIDmode
   means that no regs are mentioned anyway, and QImode means that at
   least one pattern within the insn mentions stack registers.  This
   information is valid until after reg_to_stack returns, and is used
   from jump_optimize.


BTW, is there a maintainer for reg-stack.c? If there is none, how
can I get the fix into it? I am enclosing a new patch. It is more
conservative than the previous one.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)
----
http://www.cygnus.com/ml/egcs-bugs/1998-Jul/0147.html

Fri Jul 31 17:12:42 1998  H.J. Lu  (hjl@gnu.org)

	* reg-stack.c (straighten_stack): Handle the virtual register
	stack.

--- reg-stack.c.orig	Tue Jul 14 07:26:51 1998
+++ reg-stack.c	Fri Jul 31 17:11:39 1998
@@ -298,7 +298,7 @@ mark_regs_pat (pat, set)
      SET_HARD_REG_BIT (*set, regno);
 }
 
-/* Reorganise the stack into ascending numbers,
+/* Reorganise the virtual register stack into ascending numbers,
    after this insn.  */
 
 static void
@@ -306,15 +306,28 @@ straighten_stack (insn, regstack)
      rtx insn;
      stack regstack;
 {
-  struct stack_def temp_stack;
-  int top;
+  if (regstack->top > 0)
+    {
+      /* The virtual register stack is used to convert the "flat
+	 register file" model that gcc uses, to a stack convention
+	 that the 387 uses. We only need to straighten out the
+	 register stack if there are more then one virtual register.
+	 When there is only one virtual register on the virtual
+	 register stack, it means all the previous instructions which
+	 use the virtual registers are correctly converted to use the
+	 hard registers. When there is only one register on the
+	 virtual register stack, that virtual register number doesn't
+	 have to be FIRST_STACK_REG. */
+      struct stack_def temp_stack;
+      int top;
 
-  temp_stack.reg_set = regstack->reg_set;
+      temp_stack.reg_set = regstack->reg_set;
 
-  for (top = temp_stack.top = regstack->top; top >= 0; top--)
-     temp_stack.reg[top] = FIRST_STACK_REG + temp_stack.top - top;
+      for (top = temp_stack.top = regstack->top; top >= 0; top--)
+	temp_stack.reg[top] = FIRST_STACK_REG + temp_stack.top - top;
   
-  change_stack (insn, regstack, &temp_stack, emit_insn_after);
+      change_stack (insn, regstack, &temp_stack, emit_insn_after);
+    }
 }
 
 /* Pop a register from the stack */


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