Commit Graph

14 Commits

Author SHA1 Message Date
Juergen Ributzka e117992f00 [Stackmaps] Update the stackmap format to use 64-bit relocations for the 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>

llvm-svn: 205254
2014-03-31 22:14:04 +00:00
Juergen Ributzka fb4d648295 [Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic.
Re-applying the patch, but this time without using AsmPrinter methods.

Reviewed by Andy

llvm-svn: 200481
2014-01-30 18:58:27 +00:00
Juergen Ributzka f6f0ce903e Revert "[Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic."
This reverts commit r200444 to unbreak buildbots.

llvm-svn: 200445
2014-01-30 03:34:02 +00:00
Juergen Ributzka aece7583a7 [Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic.
Reviewed by Andy

llvm-svn: 200444
2014-01-30 03:06:14 +00:00
NAKAMURA Takumi 80a474c1c3 llvm/test/CodeGen/X86/anyregcc.ll: Add explicit -mtriple=x86_64-unknown-unknown.
XMM(s) are really spilling for targeting Win64.

llvm-svn: 198999
2014-01-11 09:23:44 +00:00
Juergen Ributzka 976d94b834 [anyregcc] Fix callee-save mask for anyregcc
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.

llvm-svn: 198985
2014-01-11 01:00:27 +00:00
Andrew Trick e8cba373a3 Grow the stackmap/patchpoint format to hold 64-bit IDs.
llvm-svn: 197255
2013-12-13 18:37:10 +00:00
Andrew Trick 8d6a658430 Liveness Analysis Pass
llvm-svn: 197254
2013-12-13 18:37:03 +00:00
Andrew Trick 391dbadb51 StackMap: Implement support for DirectMemRefOp.
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.

llvm-svn: 195712
2013-11-26 02:03:25 +00:00
Andrew Trick 0ab5ba8c35 Use symbolic operands in the patchpoint folding routine and fix a spilling bug.
Fixes <rdar://15487687> [JS] AnyRegCC argument ends up being spilled

llvm-svn: 195094
2013-11-19 03:29:59 +00:00
Andrew Trick 10d5be4e6e Added a size field to the stack map record to handle subregister spills.
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.

llvm-svn: 194942
2013-11-17 01:36:23 +00:00
Andrew Trick a28099fdd4 Fix the recently added anyregcc convention to handle spilled operands.
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.

llvm-svn: 194428
2013-11-11 22:40:25 +00:00
Juergen Ributzka 87ed906b2e [Stackmap] Materialize the jump address within the patchpoint noop slide.
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

llvm-svn: 194306
2013-11-09 01:51:33 +00:00
Juergen Ributzka 9969d3e6e8 [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.
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

llvm-svn: 194293
2013-11-08 23:28:16 +00:00