[llvm-commits] [llvm] r158087 - in /llvm/trunk: lib/Target/X86/X86FrameLowering.cpp lib/Target/X86/X86RegisterInfo.cpp lib/Target/X86/X86RegisterInfo.h test/CodeGen/X86/alloca-align-rounding-32.ll test/CodeGen/X86/alloca-align-rounding.ll test/Co

[Chad Rosier]

On Jun 15, 2012, at 6:07 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Fri, Jun 15, 2012 at 6:06 PM, Chad Rosier <mcrosier at apple.com> wrote:
> Chandler, please revert.
> 
> Thanks, is there anything we can do to help fix the underlying issue?

I understand the underlying issue, but I'm not familiar enough with the frame handling code to point you in the right direction this very moment.  Essentially, the pops should be relative to the BP (RBX I believe), not the SP.

> Matt and I stared at it a bit, and it seems like there may be completely missing handling of the particular combination of features that this patch enables in a few places. If there is somewhere we can contribute patches to, let us know?

I saw no CodeGen changes across the test-suite, but of course that's not your use case (i.e. the test-suite doesn't force stack alignment).  Finding the bugs are very helpful.. And test cases! :). Beyond that I don't have any great suggestions.

 Chad

>  
> 
>  Chad
> 
> 
> 
> On Jun 15, 2012, at 5:47 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> On Fri, Jun 15, 2012 at 5:41 PM, Chad Rosier <mcrosier at apple.com> wrote:
>> Hi Matt,
>> I just wanted to let you know I'm working on a fix for this.  There's actually two issues going on here: (1) the issue you've pointed out and (2) the -mstackrealignment is forcing realignment when it's not necessary (i.e., the ABI alignment is >= then the forced alignment).  I haven't figured out a fix for (1), but I have a solution for (2) and fixing that will solve your problem.  Hopefully, I'll have this done in the next few days.  If you need a fix before then feel free to revert this commit.
>> 
>> Unfortunately, the case we're hitting is actually #1, I suspect it's just this repro that is solved by #2. We might be able to adapt the repro to work w/ normal x86 and demonstrate this issue even w/ #2 solved.
>> 
>> We're blocked on this, can we revert and carry on?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120615/fdccca5e/attachment.html>