[LLVMbugs] [Bug 10841] [AVX] crash due to aligned move being used for register spill with 48 byte offset from %rbp

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Sep 15 17:27:10 PDT 2011


http://llvm.org/bugs/show_bug.cgi?id=10841

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #2 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com> 2011-09-15 19:27:09 CDT ---
Hi Matt,

It happens that we have a big problem here. An explanation follows:

- The function in the bitcode you submitted doesn't have any 256-bit arguments,
and based on x86_64 abi the default stack alignment should be 128-bit (it can
be 256-bit if you have 256-bit arguments on the stack).
- Since there're spill slots of 32 bytes, that triggers stack realignment.
- Since there're dynamic allocas, it triggers dynamic allocation.

We don't really support dynamic allocation and stack re-alignment at the same
time.  See X86InstrInfo.cpp:433:

  // FIXME: Currently we don't support stack realignment for functions with
  //        variable-sized allocas.
  // FIXME: It's more complicated than this...
  if (0 && requiresRealignment && MFI->hasVarSizedObjects())
    report_fatal_error(
      "Stack realignment in presence of dynamic allocas is not supported");

This would require a great amount of work that I'm not even quite sure if it's
worth doing: the implementation could be somewhat nasty and the resulting code
slow. As a hack, If we set the stack alignment to 256-bits by default, we
become non-ABI compliant and code calling those functions could break. Is there
any way you can change your front-end to emit all allocas in the entry block?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list