This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix AMD64 handling of functions with huge stack frames (take 2)
> On Thu, Oct 23, 2003 at 11:35:51AM -0700, Richard Henderson wrote:
> > > + [(set (attr "type")
> > > + (if_then_else (eq_attr "alternative" "0")
> > > + (const_string "alu")
> > > + (const_string "lea")))
> >
> > (set_attr "type" "alu,lea")
> > ?
>
> Changed, thanks.
>
> Further testing revealed two further problems:
> 1) pro_epilogue_adjust_stack_rex64 happily emitted subq $2147483648, %rsp
> instead of addq $-2147483648, %rsp
> 2) many places in reload1.c used int instead of HOST_WIDE_INT
>
> This patch passed testing on AMD64, IA64 and IA32.
> 20031023-4.c test fails on PPC64 and 20031023-{1,2,3,4}.c fail on S390x,
> but I assume those are architecture dependent problems which I'll try
> to tackle next.
> Ok to commit in this shape?
>
> With stack frames > 2GB, at least on AMD64, generated code is quite
> inefficient (at -O2):
> bar:
> pushq %rbx
> movabsq $-4294967296, %r11
> movabsq $4294967296, %rax
> movabsq $-4294967296, %rdx
> movabsq $4294967296, %rcx
> addq %r11, %rsp
> addq %rsp, %rax
> addq %rsp, %rcx
> movb $97, (%rax,%rdx)
> movl $4294967295, %eax
> movq %rcx, %rbx
> leaq (%rcx,%rax), %rax
> addq %rdx, %rbx
> movq %rbx, %rdi
> movb $98, (%rax,%rdx)
> ...
> Looks some at least minimal CSE pass when stack frames are big wouldn't
> hurt. reload1.c doesn't see that %rax + %rdx is actually
> (%rsp + 4294967296) + (-4294967296) == %rsp etc.
It would perhaps help to force existence of frame pointer in some
cases... but still I think the perofmrance is secondary in these side
cases at this moment.
Thank you for digging into this! Hope this will ever take end.
The x86-64 specific part of your patch is OK.
Honza