aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/StackMaps.cpp
AgeCommit message (Collapse)AuthorFilesLines
2014-04-22[Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth1-2/+2
define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
2014-03-31[Stackmaps] Update the stackmap format to use 64-bit relocations for the ↵Juergen Ributzka1-20/+36
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-04[cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth1-1/+1
llvm-svn: 202811
2014-03-02[C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer1-4/+4
Remove the old functions. llvm-svn: 202636
2014-02-10[Stackmaps] Cleanup code. No functional change intended.Juergen Ributzka1-25/+16
llvm-svn: 201115
2014-01-30[Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka1-0/+24
stackmap/patchpoint intrinsic. Re-applying the patch, but this time without using AsmPrinter methods. Reviewed by Andy llvm-svn: 200481
2014-01-30Revert "[Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka1-24/+0
stackmap/patchpoint intrinsic." This reverts commit r200444 to unbreak buildbots. llvm-svn: 200445
2014-01-30[Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka1-0/+24
stackmap/patchpoint intrinsic. Reviewed by Andy llvm-svn: 200444
2014-01-24Fix known typosAlp Toker1-1/+1
Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
2014-01-09llvm.experimental.stackmap: fix encoding of large constants.Andrew Trick1-1/+4
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
2014-01-07Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth1-3/+1
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
2013-12-14[Stackmap] Refactor operand parsing.Juergen Ributzka1-91/+74
llvm-svn: 197329
2013-12-14[Stackmap] Liveness Analysis PassJuergen Ributzka1-13/+105
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
2013-12-13Revert "Liveness Analysis Pass"Andrew Trick1-106/+13
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
2013-12-13Grow the stackmap/patchpoint format to hold 64-bit IDs.Andrew Trick1-7/+6
llvm-svn: 197255
2013-12-13Liveness Analysis PassAndrew Trick1-12/+105
llvm-svn: 197254
2013-11-29Refactor a lot of patchpoint/stackmap related code to simplify and make itLang Hames1-6/+58
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
2013-11-27Show stackmap entry encodings in stackmap debug logs. This makes it easier toLang Hames1-23/+27
cross-reference debug output with encoded stack-maps, and to create stackmap test-cases. llvm-svn: 195874
2013-11-19Obvious pasto survived a couple rounds of cleanup.Andrew Trick1-2/+1
Caught by Aaron Ballman. llvm-svn: 195138
2013-11-19Add an abstraction to handle patchpoint operands.Andrew Trick1-4/+84
Hard-coded operand indices were scattered throughout lowering stages and layers. It was super bug prone. llvm-svn: 195093
2013-11-17Added a size field to the stack map record to handle subregister spills.Andrew Trick1-5/+15
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-08[Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka1-1/+12
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-08Fix some minor issues with r194282 to get the tree healthy again.Lang Hames1-1/+2
llvm-svn: 194284
2013-11-08Add a method to get the object-file appropriate stack map section.Lang Hames1-2/+1
Thanks to Eric Christopher for the tips on the appropriate way to do this. llvm-svn: 194282
2013-10-31Unused variableAndrew Trick1-0/+1
llvm-svn: 193819
2013-10-31Add support for stack map generation in the X86 backend.Andrew Trick1-0/+213
Originally implemented by Lang Hames. llvm-svn: 193811
generated by cgit v1.1 at 2025-10-19 05:52:46 +0000