This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: i370 patches against egcs-1.1.2
- To: Linas Vepstas <linas at linas dot org>, egcs-patches at egcs dot cygnus dot com
- Subject: Re: i370 patches against egcs-1.1.2
- From: Richard Henderson <rth at cygnus dot com>
- Date: Sat, 8 May 1999 02:51:37 -0700
- References: <199905070655.BAA01739@shadygrove.linas.org>
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~