| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This simplifies the hinting code quite a bit while making the targets
easier to write at the same time.
llvm-svn: 169173
|
|
|
|
|
|
|
|
| |
unreachable code in MachineModuleInfo
reviewed by Evan Cheng <evan.cheng@apple.com>
llvm-svn: 169164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TargetRegisterInfo::getRegAllocationHints() function is going to
replace the existing mechanisms for providing target-dependent hints to
the register allocator: ResolveRegAllocHint() and
getRawAllocationOrder().
The new hook is more flexible because it allows the target to provide
multiple preferred candidate registers for each virtual register, and it
is easier to use because targets are not required to return a reference
to a constant array like getRawAllocationOrder().
An optional VirtRegMap argument can be used to provide target-dependent
hints that depend on the provisional assignments of other virtual
registers.
llvm-svn: 169154
|
|
|
|
|
|
| |
Thanks Eric for the review.
llvm-svn: 169142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 169111
|
|
|
|
|
|
|
| |
Assertion failed: (TopRPTracker.getPos() == RegionBegin && "bad initial Top tracker").
rdar://12790302.
llvm-svn: 169072
|
|
|
|
|
|
|
| |
Assertion failed: (VNI && "No value to read by operand")
rdar://12790267.
llvm-svn: 169071
|
|
|
|
|
|
|
| |
Assertion failed: (itr != mi2iMap.end() && "Instruction not found in maps.")
rdar://12777252.
llvm-svn: 169070
|
|
|
|
|
|
|
|
| |
assert (RemainingInstrs == 0 && "Instruction count mismatch!")
rdar://12776937.
llvm-svn: 169069
|
|
|
|
|
|
|
|
|
|
|
| |
The TwoAddressInstructionPass takes the machine code out of SSA form by
expanding REG_SEQUENCE instructions into copies. It is no longer
necessary to rewrite the registers used by a REG_SEQUENCE instruction
because the new coalescer algorithm can do it now.
REG_SEQUENCE is just converted to a sequence of sub-register copies now.
llvm-svn: 169067
|
|
|
|
|
|
|
|
|
| |
part of the compile unit CU and start separating out information into
the various sections that will be pulled out later.
WIP.
llvm-svn: 169061
|
|
|
|
|
|
|
|
|
|
|
| |
MachineCopyPropagation doesn't understand super-register liveness well
enough to be able to remove implicit defs of super-registers.
This fixes a problem in ARM/2012-01-26-CopyPropKills.ll that is exposed
by an future TwoAddressInstructionPass change. The KILL instructions are
removed before the machine code is emitted.
llvm-svn: 169060
|
|
|
|
|
|
|
|
|
|
|
| |
The original patch removed a bunch of code that the SjLjEHPrepare pass placed
into the entry block if all of the landing pads were removed during the
CodeGenPrepare class. The more natural way of doing things is to run the CGP
*before* we run the SjLjEHPrepare pass.
Make it so!
llvm-svn: 169044
|
|
|
|
| |
llvm-svn: 168952
|
|
|
|
| |
llvm-svn: 168932
|
|
|
|
|
|
|
|
| |
This was found by MSVC10's STL debug mode on a test from the test suite. Sadly
std::is_heap isn't standard so there is no way to assert this without writing
our own heap verify, which looks like overkill to me.
llvm-svn: 168885
|
|
|
|
|
|
|
| |
If we need to split the operand of a VSELECT, it must be the mask operand. We
split the entire VSELECT operand with EXTRACT_SUBVECTOR.
llvm-svn: 168883
|
|
|
|
|
|
|
|
| |
computing the legalization method for vectors
For some targets, it is desirable to prefer scalarizing <N x i1> instead of promoting to a larger legal type, such as <N x i32>.
llvm-svn: 168882
|
|
|
|
|
|
| |
This saves a bit of memory.
llvm-svn: 168852
|
|
|
|
|
|
|
|
|
| |
This could cause miscompilations in targets where sub-register
composition is not always idempotent (ARM).
<rdar://problem/12758887>
llvm-svn: 168837
|
|
|
|
|
|
| |
loads do not alias.
llvm-svn: 168832
|
|
|
|
|
|
|
|
|
|
|
| |
No functional change, just moved header files.
Targets can inject custom passes between register allocation and
rewriting. This makes it possible to tweak the register allocation
before rewriting, using the full global interference checking available
from LiveRegMatrix.
llvm-svn: 168806
|
|
|
|
|
|
|
|
|
|
|
| |
This is a simple, cheap infrastructure for analyzing the shape of a
DAG. It recognizes uniform DAGs that take the shape of bottom-up
subtrees, such as the included matrix multiplication example. This is
useful for heuristics that balance register pressure with ILP. Two
canonical expressions of the heuristic are implemented in scheduling
modes: -misched-ilpmin and -misched-ilpmax.
llvm-svn: 168773
|
|
|
|
| |
llvm-svn: 168772
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a hole in the "cheap" alias analysis logic implemented within
the DAG builder itself, regardless of whether proper alias analysis is
enabled. It now handles this pattern produced by LSR+CodeGenPrepare.
%sunkaddr1 = ptrtoint * %obj to i64
%sunkaddr2 = add i64 %sunkaddr1, %lsr.iv
%sunkaddr3 = inttoptr i64 %sunkaddr2 to i32*
store i32 %v, i32* %sunkaddr3
llvm-svn: 168768
|
|
|
|
| |
llvm-svn: 168767
|
|
|
|
|
|
|
| |
The *Impl class no longer serves a purpose now that the super-class
implementation is in CodeGen.
llvm-svn: 168759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Target library is not allowed to depend on the large CodeGen
library, but the TRI and TII classes provide abstract interfaces that
require both caller and callee to link to CodeGen.
The implementation files for these classes provide default
implementations of some of the hooks. These methods may need to
reference CodeGen, so they belong in that library.
We already have a number of methods implemented in the
TargetInstrInfoImpl sub-class because of that. I will merge that class
into the parent next.
llvm-svn: 168758
|
|
|
|
| |
llvm-svn: 168751
|
|
|
|
|
|
| |
the coding standard would like.
llvm-svn: 168737
|
|
|
|
| |
llvm-svn: 168736
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
boundaries.
Given the following case:
BB0
%vreg1<def> = SUBrr %vreg0, %vreg7
%vreg2<def> = COPY %vreg7
BB1
%vreg10<def> = SUBrr %vreg0, %vreg2
We should be able to CSE between SUBrr in BB0 and SUBrr in BB1.
rdar://12462006
llvm-svn: 168717
|
|
|
|
| |
llvm-svn: 168712
|
|
|
|
|
|
|
|
|
|
|
| |
argument. Instead, use a pair of .local and .comm directives.
This avoids spurious differences between binaries built by the
integrated assembler vs. those built by the external assembler,
since the external assembler may impose alignment requirements
on .lcomm symbols where the integrated assembler does not.
llvm-svn: 168704
|
|
|
|
|
|
| |
and O0 + debug codegen.
llvm-svn: 168680
|
|
|
|
| |
llvm-svn: 168670
|
|
|
|
| |
llvm-svn: 168664
|
|
|
|
| |
llvm-svn: 168663
|
|
|
|
| |
llvm-svn: 168660
|
|
|
|
| |
llvm-svn: 168659
|
|
|
|
| |
llvm-svn: 168644
|
|
|
|
|
|
| |
add a TODO for starting.
llvm-svn: 168643
|
|
|
|
| |
llvm-svn: 168638
|
|
|
|
| |
llvm-svn: 168637
|
|
|
|
| |
llvm-svn: 168633
|
|
|
|
|
|
|
|
|
| |
r168627), we no longer need to call the freezeReservedRegs() function a second
time. Previously, this pass was conservatively adding the FP to the set of
reserved registers, requiring the second update to the reserved registers.
rdar://12719844
llvm-svn: 168631
|
|
|
|
|
|
|
|
|
| |
r168627), we no longer need to call the freezeReservedRegs() function a second
time. Previously, this pass was conservatively adding the FP to the set of
reserved registers, requiring the second update to the reserved registers.
rdar://12719844
llvm-svn: 168630
|
|
|
|
| |
llvm-svn: 168622
|
|
|
|
| |
llvm-svn: 168608
|