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: Mike Stump <mikestump at comcast dot net>
- To: sellcey at imgtec dot com
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 5 Oct 2015 10:49:43 -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>
On Oct 5, 2015, at 9:46 AM, Steve Ellcey <sellcey@imgtec.com> wrote:
> One example of an issue I have run into is with the DWARF unwind
> generation and 'Rule 16' in dwarf2cfi.c. It assumes the AND instruction
> has an integer constant argument but MIPS can't do an AND with a
> constant like -16 so it has to put it in a register first and do the AND
> with the register.
If you are using any detail about the architecture to imagine limitations with dwarf generation, then I think you’re missing that fact that the validity of the dwarf can be uncoupled from target considerations. See dwarf_pattern on frv for example, or more generally REG_FRAME_RELATED_EXPR on all the ports. When _must_ one use this? Whenever the generated dwarf is other than trivial. If trivial, it will usually just work.
You didn’t include a lot of detail in your email, so I’m just extrapolating that I think you did and what you saw.