summaryrefslogtreecommitdiff
path: root/test/CodeGen/X86/anyregcc.ll
Commit message (Collapse)AuthorAge
* [Stackmaps] Update the stackmap format to use 64-bit relocations for the ↵Juergen Ributzka2014-03-31
| | | | | | | | | | | | function address and properly align all entries. This commit updates the stackmap format to version 1 to indicate the reorganizaion of several fields. This was done in order to align stackmap entries to their natural alignment and to minimize padding. Fixes <rdar://problem/16005902> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205254 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | | | stackmap/patchpoint intrinsic. Re-applying the patch, but this time without using AsmPrinter methods. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200481 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | stackmap/patchpoint intrinsic." This reverts commit r200444 to unbreak buildbots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200445 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | stackmap/patchpoint intrinsic. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200444 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/test/CodeGen/X86/anyregcc.ll: Add explicit -mtriple=x86_64-unknown-unknown.NAKAMURA Takumi2014-01-11
| | | | | | XMM(s) are really spilling for targeting Win64. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198999 91177308-0d34-0410-b5e6-96231b3b80d8
* [anyregcc] Fix callee-save mask for anyregccJuergen Ributzka2014-01-11
| | | | | | | Use separate callee-save masks for XMM and YMM registers for anyregcc on X86 and select the proper mask depending on the target cpu we compile for. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198985 91177308-0d34-0410-b5e6-96231b3b80d8
* Grow the stackmap/patchpoint format to hold 64-bit IDs.Andrew Trick2013-12-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197255 91177308-0d34-0410-b5e6-96231b3b80d8
* Liveness Analysis PassAndrew Trick2013-12-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197254 91177308-0d34-0410-b5e6-96231b3b80d8
* StackMap: Implement support for DirectMemRefOp.Andrew Trick2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195712 91177308-0d34-0410-b5e6-96231b3b80d8
* Use symbolic operands in the patchpoint folding routine and fix a spilling bug.Andrew Trick2013-11-19
| | | | | | Fixes <rdar://15487687> [JS] AnyRegCC argument ends up being spilled git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195094 91177308-0d34-0410-b5e6-96231b3b80d8
* Added a size field to the stack map record to handle subregister spills.Andrew Trick2013-11-17
| | | | | | | | Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194942 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the recently added anyregcc convention to handle spilled operands.Andrew Trick2013-11-11
| | | | | | | | | | | | Fixes <rdar://15432754> [JS] Assertion: "Folded a def to a non-store!" The primary purpose of anyregcc is to prevent a patchpoint's call arguments and return value from being spilled. They must be available in a register, although the calling convention does not pin the register. It's up to the front end to avoid using this convention for calls with more arguments than allocatable registers. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194428 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Materialize the jump address within the patchpoint noop slide.Juergen Ributzka2013-11-09
| | | | | | | | | | | | | | | This patch moves the jump address materialization inside the noop slide. This enables patching of the materialization itself or its complete removal. This patch also adds the ability to define scratch registers that can be used safely by the code called from the patchpoint intrinsic. At least one scratch register is required, because that one is used for the materialization of the jump address. This patch depends on D2009. Differential Revision: http://llvm-reviews.chandlerc.com/D2074 Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194306 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-08
The idea of the AnyReg Calling Convention is to provide the call arguments in registers, but not to force them to be placed in a paticular order into a specified set of registers. Instead it is up tp the register allocator to assign any register as it sees fit. The same applies to the return value (if applicable). Differential Revision: http://llvm-reviews.chandlerc.com/D2009 Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194293 91177308-0d34-0410-b5e6-96231b3b80d8