This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR65416, alloca on xtensa


On Fri, Mar 13, 2015 at 7:54 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> 1. in windowed ABI stack pointer update is always split into two opcodes:
>   add and movsp. How gcc optimization passes are supposed to know that
>   'movsp' is related to 'add' and that stack allocation is complete only after
>   movsp?

The movsp has a data dependency on the add, so that is not the
problem. The real problem (which you identify) is that the optimizer
isn't recognizing that the stack allocation isn't complete until the
movsp is done.

In the bug, the optimizer recognizes that a3 = sp +  32, and so it
uses a3 before it updates sp to get a better schedule, but doesn't
realize that the stack space hasn't been allocated yet.

It looks to me like the optimizer has finally gotten smart enough that
we need to implement one of the save_stack_* patterns instead of what
we have now.


> 2. alloca seems to make an additional 16-bytes padding to each stack
>   allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
>   moves it by 48 bytes, etc. This padding looks unnecessary to me: either
>   this space is not used (previous register frame is not spilled), or alloca
>   exception handler will take care about reloading or moving spilled registers
>   to a new location. In both cases after movsp this space is just wasted.
>   Do you know why this padding may be needed?

Answering this question definitively requires some time with the ABI
manual, which I don't have. You may be right, but I would check what
XCC does in this case. It is far better tested.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]