MC: Clean up method names in MCContext.

The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.

llvm-svn: 237594

[Statepoints] Support for "patchable" statepoints.

Summary:
This change adds two new parameters to the statepoint intrinsic, `i64 id`
and `i32 num_patch_bytes`. `id` gets propagated to the ID field

[Statepoints] Support for "patchable" statepoints.

Summary:
This change adds two new parameters to the statepoint intrinsic, `i64 id`
and `i32 num_patch_bytes`. `id` gets propagated to the ID field
in the generated StackMap section. If the `num_patch_bytes` is
non-zero then the statepoint is lowered to `num_patch_bytes` bytes of
nops instead of a call (the spill and reload code remains unchanged).
A non-zero `num_patch_bytes` is useful in situations where a language
runtime requires complete control over how a call is lowered.

This change brings statepoints one step closer to patchpoints. With
some additional work (that is not part of this patch) it should be
possible to get rid of `TargetOpcode::STATEPOINT` altogether.

PlaceSafepoints generates `statepoint` wrappers with `id` set to
`0xABCDEF00` (the old default value for the ID reported in the stackmap)
and `num_patch_bytes` set to `0`. This can be made more sophisticated
later.

Reviewers: reames, pgavlin, swaroop.sridhar, AndyAyers

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9546

llvm-svn: 237214

show more ...

[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr.

AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a
reference for this is crufty.

llvm-svn: 235752

Remove dead calls and function arguments dealing with TRI in StackMaps.

llvm-svn: 232847

Rewrite StackMap location handling to pre-compute the dwarf register
numbers before emission.

This removes a dependency on being able to access TRI at the module
level and is similar to the DwarfExp

Rewrite StackMap location handling to pre-compute the dwarf register
numbers before emission.

This removes a dependency on being able to access TRI at the module
level and is similar to the DwarfExpression handling. I've modified
the debug support into print/dump routines that'll do the same dumping
but is now callable anywhere and if TRI isn't available will go ahead
and just print out raw register numbers.

llvm-svn: 232821

show more ...

Use the cached subtarget on the MachineFunction when the AsmPrinter
will have a MachineFunction, i.e. in places other than the module
level doInitialize/doFinalize.

llvm-svn: 232783

Use the cached subtarget off of the machine function.

llvm-svn: 232129

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine.

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.

*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.

llvm-svn: 227113

show more ...

[StackMaps] Use CurrentFnSymForSize

When computing the call-site offset, use AP.CurrentFnSymForSize instead of
AP.CurrentFnSym. There should be no change for other targets, but this is
necessary for

[StackMaps] Use CurrentFnSymForSize

When computing the call-site offset, use AP.CurrentFnSymForSize instead of
AP.CurrentFnSym. There should be no change for other targets, but this is
necessary for generating valid expressions for PPC64/ELF.

llvm-svn: 225807

show more ...

[Statepoints 2/4] Statepoint infrastructure for garbage collection: MI & x86-64 Backend

This is the second patch in a small series. This patch contains the MachineInstruction and x86-64 backend pie

[Statepoints 2/4] Statepoint infrastructure for garbage collection: MI & x86-64 Backend

This is the second patch in a small series. This patch contains the MachineInstruction and x86-64 backend pieces required to lower Statepoints. It does not include the code to actually generate the STATEPOINT machine instruction and as a result, the entire patch is currently dead code. I will be submitting the SelectionDAG parts within the next 24-48 hours. Since those pieces are by far the most complicated, I wanted to minimize the size of that patch. That patch will include the tests which exercise the functionality in this patch. The entire series can be seen as one combined whole in http://reviews.llvm.org/D5683.

The STATEPOINT psuedo node is generated after all gc values are explicitly spilled to stack slots. The purpose of this node is to wrap an actual call instruction while recording the spill locations of the meta arguments used for garbage collection and other purposes. The STATEPOINT is modeled as modifing all of those locations to prevent backend optimizations from forwarding the value from before the STATEPOINT to after the STATEPOINT. (Doing so would break relocation semantics for collectors which wish to relocate roots.)

The implementation of STATEPOINT is closely modeled on PATCHPOINT. Eventually, much of the code in this patch will be removed. The long term plan is to merge the functionality provided by statepoints and patchpoints. Merging their implementations in the backend is likely to be a good starting point.

Reviewed by: atrick, ributzka

llvm-svn: 223085

show more ...

The patchpoint lowering logic would crash with live constants equal to
the tombstone or empty keys of a DenseMap<int64_t, T>. This patch
fixes the issue (and adds a tests case).

llvm-svn: 221214

Change logic in StackMaps::recordStackMapOpers to use the isInt<32>
predicate instead of bitwise operations.

This is not a functional change.

llvm-svn: 221209

Remove unnecessary copying or replace it with moves in a bunch of places.

NFC.

llvm-svn: 219061

Have MachineFunction cache a pointer to the subtarget to make lookups
shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lo

Have MachineFunction cache a pointer to the subtarget to make lookups
shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lookups from
the MachineFunction easily.

Update the MIPS subtarget switching machinery to update this pointer
at the same time it runs.

llvm-svn: 214838

show more ...

Remove the TargetMachine forwards for TargetSubtargetInfo based
information and update all callers. No functional change.

llvm-svn: 214781

Explicitly report runtime stack realignment in StackMap section

This change adds code to explicitly mark a function which requires runtime stack realignment as not having a fixed frame size in the S

Explicitly report runtime stack realignment in StackMap section

This change adds code to explicitly mark a function which requires runtime stack realignment as not having a fixed frame size in the StackMap section. As it happens, this is not actually a functional change. The size that would be reported without the check is also "-1", but as far as I can tell, that's an accident. The code change makes this explicit.

Note: There's a separate bug in handling of stackmaps and patchpoints in functions which need dynamic frame realignment. The current code assumes that offsets can be calculated from RBP, but realigned frames must use RSP. (There's a variable gap between RBP and the spill slots.) This change set does not address that issue.

Reviewers: atrick, ributzka

Differential Revision: http://reviews.llvm.org/D4572

llvm-svn: 214534

show more ...

[Stackmaps] Pacify windows buildbot.

llvm-svn: 207807

[Stackmaps] Add command line option to specify the stackmap version.

llvm-svn: 207805

[Stackmaps] Refactor serialization code. No functional change intended.

llvm-svn: 207804

[Stackmaps] Replace the custom ConstantPool class with a MapVector.

llvm-svn: 207803

[Modules] Remove potential ODR violations by sinking the DEBUG_TYPE
define below all header includes in the lib/CodeGen/... tree. While the
current modules implementation doesn't check for this kind

[Modules] Remove potential ODR violations by sinking the DEBUG_TYPE
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

show more ...

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

[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

show more ...

[cleanup] Re-sort all the includes with utils/sort_includes.py.

llvm-svn: 202811

[C++11] Replace llvm::next and llvm::prior with std::next and std::prev.

Remove the old functions.

llvm-svn: 202636

[Stackmaps] Cleanup code. No functional change intended.

llvm-svn: 201115