[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:

[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

show more ...

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

[Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic.

Reviewed by Andy

llvm-svn: 200444

Fix known typos

Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.

llvm-svn: 200018

llvm.experimental.stackmap: fix encoding of large constants.

In the stackmap format we advertise the constant field as signed.
However, we were determining whether to promote to a 64-bit constant
po

llvm.experimental.stackmap: fix encoding of large constants.

In the stackmap format we advertise the constant field as signed.
However, we were determining whether to promote to a 64-bit constant
pool based on an unsigned comparison.

This fix allows -1 to be encoded as a small constant.

llvm-svn: 198816

show more ...

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also com

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685

show more ...

[Stackmap] Refactor operand parsing.

llvm-svn: 197329

[Stackmap] Liveness Analysis Pass

This optional register liveness analysis pass can be enabled with either
-enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass
traverses each ba

[Stackmap] Liveness Analysis Pass

This optional register liveness analysis pass can be enabled with either
-enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass
traverses each basic block in a machine function. For each basic block the
instructions are processed in reversed order and if a patchpoint or stackmap
instruction is encountered the current live-out register set is encoded as a
register mask and attached to the instruction.

Later on during stackmap generation the live-out register mask is processed and
also emitted as part of the stackmap.

This information is optional and intended for optimization purposes only. This
will enable a client of the stackmap to reason about the registers it can use
and which registers need to be preserved.

Reviewed by Andy

llvm-svn: 197317

show more ...

Revert "Liveness Analysis Pass"

This reverts commit r197254.

This was an accidental merge of Juergen's patch. It will be checked in
shortly, but wasn't meant to go in quite yet.

Conflicts:
includ

Revert "Liveness Analysis Pass"

This reverts commit r197254.

This was an accidental merge of Juergen's patch. It will be checked in
shortly, but wasn't meant to go in quite yet.

Conflicts:
include/llvm/CodeGen/StackMaps.h
lib/CodeGen/StackMaps.cpp
test/CodeGen/X86/stackmap-liveness.ll

llvm-svn: 197260

show more ...

Grow the stackmap/patchpoint format to hold 64-bit IDs.

llvm-svn: 197255

Liveness Analysis Pass

llvm-svn: 197254

Refactor a lot of patchpoint/stackmap related code to simplify and make it
target independent.

Most of the x86 specific stackmap/patchpoint handling was necessitated by the
use of the native address

Refactor a lot of patchpoint/stackmap related code to simplify and make it
target independent.

Most of the x86 specific stackmap/patchpoint handling was necessitated by the
use of the native address-mode format for frame index operands. PEI has now
been modified to treat stackmap/patchpoint similarly to DEBUG_INFO, allowing
us to use a simple, platform independent register/offset pair for frame
indexes on stackmap/patchpoints.

Notes:
- Folding is now platform independent and automatically supported.
- Emiting patchpoints with direct memory references now just involves calling
the TargetLoweringBase::emitPatchPoint utility method from the target's
XXXTargetLowering::EmitInstrWithCustomInserter method. (See
X86TargetLowering for an example).
- No more ugly platform-specific operand parsers.

This patch shouldn't change the generated output for X86.

llvm-svn: 195944

show more ...

Show stackmap entry encodings in stackmap debug logs. This makes it easier to
cross-reference debug output with encoded stack-maps, and to create stackmap
test-cases.

llvm-svn: 195874

Obvious pasto survived a couple rounds of cleanup.

Caught by Aaron Ballman.

llvm-svn: 195138

Add an abstraction to handle patchpoint operands.

Hard-coded operand indices were scattered throughout lowering stages
and layers. It was super bug prone.

llvm-svn: 195093

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 recommendat

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

show more ...

[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

[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

show more ...

Fix some minor issues with r194282 to get the tree healthy again.

llvm-svn: 194284

Add a method to get the object-file appropriate stack map section.

Thanks to Eric Christopher for the tips on the appropriate way to do this.

llvm-svn: 194282

Unused variable

llvm-svn: 193819

Add support for stack map generation in the X86 backend.

Originally implemented by Lang Hames.

llvm-svn: 193811