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: i370 patches against egcs-1.1.2


Do you have an assignment on file for gcc?  It'll be needed.

Please do not include patches for the generated files.

Please do include a changelog entry.

Please make diffs against mainline.  No new patches will be
applied to the 1.1 release branch.


+/* We create temp files to store assembler output until we 
+ * are able to determine if the branch target is on page or off page.
+ * this should provide a significant overall performance improvement,
+ * as we will eliminate two memory accesses and two instructions
+ * for every forward branch (every if statement).
+ */

This is a terrible way to accomplish this.  Gcc has relatively
sophisticated branch-shortening code, which does exactly this
sort of optimization.  The i370 shares a lot with the SH in 
terms of having a short branch range and literal pools interspersed
with the code.

+  ap = (alias_node_t *) malloc (sizeof (alias_node_t));
+  if (ap == 0)
+    {
+      fatal ("virtual memory exhausted\n");
+      abort ();
+    }

Use xmalloc.

+int
+handle_pragma (finput, node)
+     FILE *finput;
+     tree node;

The interface to handle pragmas has changed.

+  gen_rtx(REG, TYPE_MODE (VALTYPE), RET_REG(TYPE_MODE(VALTYPE)))  

Please use gen_rtx_REG(mode,regno) instead, as it typechecks its
arguments.

+;;    (define_insn ""
+;;        [(set (match_operand:SI 0 "r_or_s_operand" "=dm,d,dm")
+;;            (match_operand:SI 1 "r_or_s_operand" "diR,dim,*fF"))]
+;;
+;; The "r_or_s_operand" predicate is used to recognize the instruction;
+;; however, it is not further used to enforce a constraint at later stages.
+;; Thus, for example, although "r_or_s_operand" bars operands of the form
+;; base+index+displacement, such operands can none-the-less show up during
+;; post-instruction-recog processing: thus, for example, garbage like
+;; MVC     152(4,r13),0(r5,r13) might be generated if both op0 and op1 are 
+;; mem operands.   To avoid this, use the R constraint.

You almost certainly want to use the pattern predicate to disallow two
memories right from the beginning.  See movsi+1 in i386.md.

+/* Basically, one big giant no-op, since the defaults used in varargs.h and
+ * stdarg.h work just fine for the 390 architecture & current linux-elf
+ * ABI: all arguments are passed on the stack, so there is no fumbling to
+ * save registers, all byte and short arguments are padded out to a full
+ * word, and the machine is big endian.  So basically, we get "args" for
+ * free.  What a deal! 
+ */

Then don't provide va-i370.h.


r~


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