[patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Dominique Dhumieres dominiq@lps.ens.fr
Mon Sep 15 12:47:00 GMT 2014


> > Perhaps it would be safer simply to revert that hunk of the original patch
> > unless/until (1) and (2) above are addressed?
>
> Given that the original patch addresses 'only' a missed-optimization
> (and causes ice-on-valid), it makes sense to me.

(1) Iain already asked the questions more than two months ago at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00374.html
without answer AFAICT.

(2) I think it is enough to revert the commit of gcc/config/i386/i386.c as

--- ../_clean/gcc/config/i386/i386.c	2014-09-12 23:04:53.000000000 +0200
+++ gcc/config/i386/i386.c	2014-09-12 15:55:34.000000000 +0200
@@ -38965,16 +38965,7 @@ x86_output_mi_thunk (FILE *file, tree, H
      For our purposes here, we can get away with (ab)using a jump pattern,
      because we're going to do no optimization.  */
   if (MEM_P (fnaddr))
-    {
-      if (sibcall_insn_operand (fnaddr, word_mode))
-	{
-	  tmp = gen_rtx_CALL (VOIDmode, fnaddr, const0_rtx);
-          tmp = emit_call_insn (tmp);
-          SIBLING_CALL_P (tmp) = 1;
-	}
-      else
-	emit_jump_insn (gen_indirect_jump (fnaddr));
-    }
+    emit_jump_insn (gen_indirect_jump (fnaddr));
   else
     {
       if (ix86_cmodel == CM_LARGE_PIC && SYMBOLIC_CONST (fnaddr))

see https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01414.html

Dominique



More information about the Gcc-patches mailing list