Revert r211399, "Generate native unwind info on Win64"

It broke Legacy JIT Tests on x86_64-{mingw32|msvc}, aka Windows x64.

llvm-svn: 211480

Generate native unwind info on Win64

This patch enables LLVM to emit Win64-native unwind info rather than
DWARF CFI. It handles all corner cases (I hope), including stack
realignment.

Because the

Generate native unwind info on Win64

This patch enables LLVM to emit Win64-native unwind info rather than
DWARF CFI. It handles all corner cases (I hope), including stack
realignment.

Because the unwind info is not flexible enough to describe stack frames
with a gap of unknown size in the middle, such as the one caused by
stack realignment, I modified register spilling code to place all spills
into the fixed frame slots, so that they can be accessed relative to the
frame pointer.

Patch by Vadim Chugunov!

Reviewed By: rnk

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

llvm-svn: 211399

show more ...

Convert several loops over MachineFunction basic blocks to range-based loops

llvm-svn: 207683

[Modules] Make Support/Debug.h modular. This requires it to not change
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO a

[Modules] Make Support/Debug.h modular. This requires it to not change
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

llvm-svn: 206822

show more ...

Break PseudoSourceValue out of the Value hierarchy. It is now the root of its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't).

Break PseudoSourceValue out of the Value hierarchy. It is now the root of its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead.

llvm-svn: 206255

show more ...

[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.

llvm-svn: 206142

Move the segmented stack switch to a function attribute

This removes the -segmented-stacks command line flag in favor of a
per-function "split-stack" attribute.

Patch by Luqman Aden and Alex Cricht

Move the segmented stack switch to a function attribute

This removes the -segmented-stacks command line flag in favor of a
per-function "split-stack" attribute.

Patch by Luqman Aden and Alex Crichton!

llvm-svn: 205997

show more ...

Make consistent use of MCPhysReg instead of uint16_t throughout the tree.

llvm-svn: 205610

[Layering] Move DebugInfo.h into the IR library where its implementation
already lives.

llvm-svn: 203046

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

Remove the old functions.

llvm-svn: 202636

Put the functionality for printing a value to a raw_ostream as an
operand into the Value interface just like the core print method is.
That gives a more conistent organization to the IR printing inte

Put the functionality for printing a value to a raw_ostream as an
operand into the Value interface just like the core print method is.
That gives a more conistent organization to the IR printing interfaces
-- they are all attached to the IR objects themselves. Also, update all
the users.

This removes the 'Writer.h' header which contained only a single function
declaration.

llvm-svn: 198836

show more ...

Move the LLVM IR asm writer header files into the IR directory, as they
are part of the core IR library in order to support dumping and other
basic functionality.

Rename the 'Assembly' include direc

Move the LLVM IR asm writer header files into the IR directory, as they
are part of the core IR library in order to support dumping and other
basic functionality.

Rename the 'Assembly' include directory to 'AsmParser' to match the
library name and the only functionality left their -- printing has been
in the core IR library for quite some time.

Update all of the #includes to match.

All of this started because I wanted to have the layering in good shape
before I started adding support for printing LLVM IR using the new pass
infrastructure, and commandline support for the new pass infrastructure.

llvm-svn: 198688

show more ...

Make the llvm mangler depend only on DataLayout.

Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.

This patch implements a compromise

Make the llvm mangler depend only on DataLayout.

Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.

This patch implements a compromise solution where the mangler uses DataLayout.
This way, any tool that already links with Target (llc, clang) gets the exact
behavior as before and new IR files can be mangled without linking with Target.

With this patch the mangler is constructed with just a DataLayout and DataLayout
is extended to include the information the Mangler needs.

llvm-svn: 198438

show more ...

[stackprotector] Use analysis from the StackProtector pass for stack layout in PEI a nd LocalStackSlot passes.

This changes the MachineFrameInfo API to use the new SSPLayoutKind information
produced

[stackprotector] Use analysis from the StackProtector pass for stack layout in PEI a nd LocalStackSlot passes.

This changes the MachineFrameInfo API to use the new SSPLayoutKind information
produced by the StackProtector pass (instead of a boolean flag) and updates a
few pass dependencies (to preserve the SSP analysis).

The stack layout follows the same approach used prior to this change - i.e.,
only LargeArray stack objects will be placed near the canary and everything
else will be laid out normally. After this change, structures containing large
arrays will also be placed near the canary - a case previously missed by the
old implementation.

Out of tree targets will need to update their usage of
MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument.

The next patch will implement the rules for sspstrong and sspreq. The end goal
is to support ssp-strong stack layout rules.

WIP.

Differential Revision: http://llvm-reviews.chandlerc.com/D2158

llvm-svn: 197653

show more ...

Fix an over-constrained assertion in MachineFunction::addLiveIn.
The assertion was checking that the virtual register VReg used to represent the
physical register PReg uses the same register class as

Fix an over-constrained assertion in MachineFunction::addLiveIn.
The assertion was checking that the virtual register VReg used to represent the
physical register PReg uses the same register class as the one passed to
MachineFunction::addLiveIn.
This is over-constraining because it is sufficient to check that the register
class of VReg (VRegRC) is a subclass of the register class of PReg (PRegRC) and
that VRegRC contains PReg.
Indeed, if VReg gets constrained because of some operation constraints
between two calls of MachineFunction::addLiveIn, the original assertion
cannot match.

This fixes <rdar://problem/15633429>.

llvm-svn: 197097

show more ...

Use function attributes to indicate that we don't want to realign the stack.

Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead

Use function attributes to indicate that we don't want to realign the stack.

Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.

llvm-svn: 187618

show more ...

Directly access objects which may change during compilation.

llvm-svn: 184121

Print ConstantPool entries initialized to Values with WriteAsOperand instead of
operator<< so that functions are printed as just their name instead of as their
entire definition, which is excessively

Print ConstantPool entries initialized to Values with WriteAsOperand instead of
operator<< so that functions are printed as just their name instead of as their
entire definition, which is excessively verbose in this context.

llvm-svn: 183871

show more ...

Move estimateStackSize from ARM into MachineFrameInfo

This is a generic function (derived from PEI); moving it into
MachineFrameInfo eliminates a current redundancy between the ARM and AArch64
backe

Move estimateStackSize from ARM into MachineFrameInfo

This is a generic function (derived from PEI); moving it into
MachineFrameInfo eliminates a current redundancy between the ARM and AArch64
backends, and will allow it to be used by the PowerPC target code.

No functionality change intended.

llvm-svn: 177111

show more ...

Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects.

Aside from the question of whether we report a warning or an error when we
can't satisfy a requested stack object align

Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects.

Aside from the question of whether we report a warning or an error when we
can't satisfy a requested stack object alignment, the current implementation
of this is not good. We're not providing any source location in the diagnostics
and the current warning is not connected to any warning group so you can't
control it. We could improve the source location somewhat, but we can do a
much better job if this check is implemented in the front-end, so let's do that
instead. <rdar://problem/13127907>

llvm-svn: 174741

show more ...

Remove liveout lists from MachineRegisterInfo.

All targets are now adding return value registers as implicit uses on
return instructions, and there is no longer a need for the live out
lists.

llvm-

Remove liveout lists from MachineRegisterInfo.

All targets are now adding return value registers as implicit uses on
return instructions, and there is no longer a need for the live out
lists.

llvm-svn: 174417

show more ...

[Stack Alignment] emit warning instead of a hard error

Per discussion in rdar://13127907, we should emit a hard error only if
people write code where the requested alignment is larger than achievabl

[Stack Alignment] emit warning instead of a hard error

Per discussion in rdar://13127907, we should emit a hard error only if
people write code where the requested alignment is larger than achievable
and assumes the low bits are zeros. A warning should be good enough when
we are not sure if the source code assumes the low bits are zeros.

rdar://13127907

llvm-svn: 174336

show more ...

Stack Alignment: throw error if we can't satisfy the minimal alignment
requirement when creating stack objects in MachineFrameInfo.

Add CreateStackObjectWithMinAlign to throw error when the minimal

Stack Alignment: throw error if we can't satisfy the minimal alignment
requirement when creating stack objects in MachineFrameInfo.

Add CreateStackObjectWithMinAlign to throw error when the minimal alignment
can't be achieved and to clamp the alignment when the preferred alignment
can't be achieved. Same is true for CreateVariableSizedObject.
Will not emit error in CreateSpillStackObject or CreateStackObject.

As long as callers of CreateStackObject do not assume the object will be
aligned at the requested alignment, we should not have miscompile since
later optimizations which look at the object's alignment will have the correct
information.

rdar://12713765

llvm-svn: 172027

show more ...

Don't call destructors on MachineInstr and MachineOperand.

The series of patches leading up to this one makes llc -O0 run 8% faster.

When deallocating a MachineFunction, there is no need to visit a

Don't call destructors on MachineInstr and MachineOperand.

The series of patches leading up to this one makes llc -O0 run 8% faster.

When deallocating a MachineFunction, there is no need to visit all
MachineInstr and MachineOperand objects to deallocate them. All their
memory come from a BumpPtrAllocator that is about to be purged, and they
have empty destructors anyway.

This only applies when deallocating the MachineFunction.
DeleteMachineInstr() should still be used to recycle MI memory during
the codegen passes.

Remove the LeakDetector support for MachineInstr. I've never seen it
used before, and now it definitely doesn't work. With this patch, leaked
MachineInstrs would be much less of a problem since all of their memory
will be reclaimed by ~MachineFunction().

llvm-svn: 171599

show more ...

Use ArrayRecycler for MachineInstr operand lists.

Instead of an std::vector<MachineOperand>, use MachineOperand arrays
from an ArrayRecycler living in MachineFunction.

This has several advantages:

Use ArrayRecycler for MachineInstr operand lists.

Instead of an std::vector<MachineOperand>, use MachineOperand arrays
from an ArrayRecycler living in MachineFunction.

This has several advantages:

- MachineInstr now has a trivial destructor, making it possible to
delete them in batches when destroying MachineFunction. This will be
enabled in a later patch.

- Bypassing malloc() and free() can be faster, depending on the system
library.

- MachineInstr objects and their operands are allocated from the same
BumpPtrAllocator, so they will usually be next to each other in
memory, providing better locality of reference.

- Reduce MachineInstr footprint. A std::vector is 24 bytes, the new
operand array representation only uses 8+4+1 bytes in MachineInstr.

- Better control over operand array reallocations. In the old
representation, the use-def chains would be reordered whenever a
std::vector reached its capacity. The new implementation never changes
the use-def chain order.

Note that some decisions in the code generator depend on the use-def
chain orders, so this patch may cause different assembly to be produced
in a few cases.

llvm-svn: 171598

show more ...