This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Patch to allow spill slot alignment greater than the stack alignment
- From: Steve Ellcey <sellcey at imgtec dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 6 Oct 2015 08:30:08 -0700
- Subject: Re: RFC: Patch to allow spill slot alignment greater than the stack alignment
- Authentication-results: sourceware.org; auth=none
- References: <1443819469 dot 8687 dot 182 dot camel at ubuntu-sellcey> <561237B9 dot 1080602 at redhat dot com> <1444061411 dot 8687 dot 207 dot camel at ubuntu-sellcey> <CAMe9rOr17KDCXzNoAZN6fgXXJ1MMu-enkDw_ykAPpSQAeiAnWQ at mail dot gmail dot com> <1444063572 dot 8687 dot 219 dot camel at ubuntu-sellcey> <CAMe9rOq5um+cOh2=ibgg10u7WDGSQP80MoDCqHszMa-uz-s3fg at mail dot gmail dot com>
- Reply-to: <sellcey at imgtec dot com>
On Mon, 2015-10-05 at 09:57 -0700, H.J. Lu wrote:
> You need to update dwarf2cfi.c to generate proper unwind info for
> whatever frame instructions MIPS generates, like what we did for
> x86 dynamic stack realignment.
The problem is understanding what the 'proper' unwind info is and
figuring out what is wrong about it when it doesn't work.
I used Bernd's comment about Rule #6 to handle the sp = sp AND reg
issue, but I have a couple of more dwarf/cfi questions.
One, can you explicitly make a copy of the stack pointer to another
register and not make that register the new stack pointer? I want to
save the old stack pointer before aligning it but when I do that I think
that dwarfcfi.c automatically assumes that the new register is now the
stack pointer and that is not what I want. I want the stack pointer to
remain as the original register.
My other question is about 'set_unexpected' and how that affects
the generated unwind info. I noticed that a lot of my failing tests use
'set_unexpected' and I don't know what this function does or how it
affects the generated code that would cause these tests in particular to
fail.
Steve Ellcey
sellcey@imgtec.com