On Fri, Mar 13, 2015 at 7:54 AM, Max Filippov <jcmvb...@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.
