Re: i386 frame pointer elimination patch

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> On Wed, Jan 19, 2000 at 07:31:47PM +0100, Jan Hubicka wrote:
> > ! static HOST_WIDE_INT ix86_compute_frame_size PARAMS((HOST_WIDE_INT, int *, int *, int *));
> > +   HOST_WIDE_INT tsize = ix86_compute_frame_size (get_frame_size (), (int *)0, (int *)0,
> 
> Please wrap for 80 columns.
OK... Sorry.
> 
> And why is virtual_stack_vars_rtx special?

I am using probably quite ill system of mathing the moves from frame_pointer.
The movsi pattern refuse them and they are matched by lea pattern only..
(because they can be actually converted to lea instruction when elimination
offset is nonzero).

virtual_stack_vars_rtx seems to be only of the virtual registers 
where attempts to store it to memory are made.

Possibly the problem is that soft frame_pointer is not in any register
class, so it don't match register_operand:
  /* We don't consider registers whose class is NO_REGS
     to be a register operand.  */
  return (GET_CODE (op) == REG
          && (REGNO (op) >= FIRST_PSEUDO_REGISTER
              || REGNO_REG_CLASS (REGNO (op)) != NO_REGS));

Am I expected to put it into some class? And which one?
Will reload like soft frame pointer appearing in the non-set instructions?

> > + ; This insn is generated by setjmp/longjmp expanders to set
> > + ; stack frame.
> > + (define_insn "*set_frame"
> > +   [(set (reg:SI 20) (reg:SI 6))]
> > +   ""
> > +   "#")
> 
> This appears to be placed after movsi_1.  Therefore it can
> never be matched.  I'm sort of concerned that you need this
> and the splitter at all -- no other soft frame pointer machine
> I'm aware of needs it.

After removing the pattern I get failure:

./libgcc2.c:3442: Unrecognizable insn:
(insn 64 62 65 (set (reg:SI 20 frame)
        (reg:SI 6 ebp)) -1 (nil)
    (nil))

while compiling _eh

Only explanation I am able to come with is that reload don't eliminate
such insn and thus it don't match constraints.
The splitter fixes this silently, but it is probably not how thinks
are expected to work.
Is reload expected to eliminate frame pointer from such pattern?
> 
> > + (define_insn "*frame_noop"
> > +   [(set (reg:SI 20) (reg:SI 20))]
> > +   "!reload_completed"
> > +   "#")
> 
> And this!  This should never have been created much less survived.
It will be similar problem. Probably there is something wrong with the
elimination.

I've just found important problem with exception handling. For some purpose
the throw now fails to find exception handler.
Interestingly enought I've missed all the failures while running the testsuite
(I did 8( )
I don't understand much to exception handling, so I am not sure why
this happends.
Hope this problem is releated to the "incomplette elimination" problem
above.
One of simple examples is flow1.c testcase:

#include <stdio.h>

int bar ()
{
  throw 100;
}

int main ()
{
  int i = 0;			// this gets deleted after flow analysis
  try
    {
      i = bar ();
    }
  catch (...)
    {
    }

  printf ("i = %d\n", i);
  return i;
}

It compiles to:

	.file	"flow1.C"
	.version	"01.01"
gcc2_compiled.:
.globl __throw
.text
	.align 16
.globl bar__Fv
	.type	 bar__Fv,@function
bar__Fv:
.LFB1:
	pushl	%ebp
.LCFI0:
	movl	%esp, %ebp
.LCFI1:
	pushl	%ebx
.LCFI2:
	subl	$4, %esp
.LCFI3:
	subl	$12, %esp
	pushl	$4
.LCFI4:
	call	__eh_alloc
	movl	%eax, %ebx
	addl	$16, %esp
	subl	$4, %esp
	movl	$100, (%ebx)
	pushl	$0
.LCFI5:
	call	__tfi
	pushl	%eax
	pushl	%ebx
.LCFI6:
	call	__cp_push_exception
	addl	$16, %esp
.LCFI7:
	call	__throw
.LFE1:
.Lfe1:
	.size	 bar__Fv,.Lfe1-bar__Fv
.globl __rethrow
		.section	.rodata
.LC0:
	.string	"i = %d\n"
.text
	.align 16
.globl main
	.type	 main,@function
main:
.LFB2:
	pushl	%ebp
.LCFI8:
	movl	%esp, %ebp
.LCFI9:
	pushl	%ebx
.LCFI10:
	xorl	%ebx, %ebx
	subl	$4, %esp
.LCFI11:
.LEHB8:
	call	bar__Fv
	movl	%eax, %ebx
.L9:
.LEHE8:
	subl	$8, %esp
	pushl	%ebx
	pushl	$.LC0
.LCFI12:
	call	printf
	movl	%ebx, %eax
	jmp	.L7
	.align 16
.L10:
	subl	$12, %esp
	pushl	$.LRTH8
	call	__rethrow
	.align 16
.L8:
.LEHB10:
.LCFI13:
	call	__start_cp_handler
	subl	$12, %esp
	pushl	%eax
.LCFI14:
	call	__cp_pop_exception
	addl	$16, %esp
	jmp	.L9
	.align 16
.L7:
	leal	-4(%ebp), %esp
	popl	%ebx
	popl	%ebp
	ret
.LEHE10:
.LFE2:
.Lfe2:
	.size	 main,.Lfe2-main
	.section	.gcc_except_table,"aw",@progbits
	.align 4
__EXCEPTION_TABLE__:
	.long	-2
	.value	4
	.value	1
.LRTH0:
.LRTH8:
	.long	.LEHB8
	.long	.LEHE8
	.long	.L8
	.long	0

.LRTH10:
	.long	.LEHB10
	.long	.LEHE10
	.long	.L10
	.long	0

.LRTH1:
	.long	-1


	.section	.eh_frame,"aw",@progbits
__FRAME_BEGIN__:
	.4byte	.LLCIE1
.LSCIE1:
	.4byte	0x0
	.byte	0x1
	.string	"eh"

	.4byte	__EXCEPTION_TABLE__
	.byte	0x1
	.byte	0x7c
	.byte	0x8
	.byte	0xc
	.byte	0x4
	.byte	0x4
	.byte	0x88
	.byte	0x1
	.align 4
.LECIE1:
	.set	.LLCIE1,.LECIE1-.LSCIE1
	.4byte	.LLFDE1
.LSFDE1:
	.4byte	.LSFDE1-__FRAME_BEGIN__
	.4byte	.LFB1
	.4byte	.LFE1-.LFB1
	.byte	0x4
	.4byte	.LCFI0-.LFB1
	.byte	0xe
	.byte	0x8
	.byte	0x85
	.byte	0x2
	.byte	0x4
	.4byte	.LCFI1-.LCFI0
	.byte	0xd
	.byte	0x5
	.byte	0x4
	.4byte	.LCFI2-.LCFI1
	.byte	0x83
	.byte	0x3
	.byte	0x4
	.4byte	.LCFI4-.LCFI2
	.byte	0x2e
	.byte	0x10
	.byte	0x4
	.4byte	.LCFI5-.LCFI4
	.byte	0x2e
	.byte	0x0
	.byte	0x4
	.4byte	.LCFI6-.LCFI5
	.byte	0x2e
	.byte	0x10
	.byte	0x4
	.4byte	.LCFI7-.LCFI6
	.byte	0x2e
	.byte	0x0
	.align 4
.LEFDE1:
	.set	.LLFDE1,.LEFDE1-.LSFDE1
	.4byte	.LLFDE3
.LSFDE3:
	.4byte	.LSFDE3-__FRAME_BEGIN__
	.4byte	.LFB2
	.4byte	.LFE2-.LFB2
	.byte	0x4
	.4byte	.LCFI8-.LFB2
	.byte	0xe
	.byte	0x8
	.byte	0x85
	.byte	0x2
	.byte	0x4
	.4byte	.LCFI9-.LCFI8
	.byte	0xd
	.byte	0x5
	.byte	0x4
	.4byte	.LCFI10-.LCFI9
	.byte	0x83
	.byte	0x3
	.byte	0x4
	.4byte	.LCFI12-.LCFI10
	.byte	0x2e
	.byte	0x10
	.byte	0x4
	.4byte	.LCFI13-.LCFI12
	.byte	0x2e
	.byte	0x0
	.byte	0x4
	.4byte	.LCFI14-.LCFI13
	.byte	0x2e
	.byte	0x10
	.align 4
.LEFDE3:
	.set	.LLFDE3,.LEFDE3-.LSFDE3
	.ident	"GCC: (GNU) 2.96 20000119 (experimental)"