| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
This change adds endian-awareness to MipsJITInfo and emitWordLE in
MipsCodeEmitter has become emitWord now to support both endianness.
Patch by Petar Jovanovic.
llvm-svn: 169177
|
| |
|
|
| |
llvm-svn: 169176
|
| |
|
|
| |
llvm-svn: 169175
|
| |
|
|
|
|
|
|
| |
code. Removing it.
Patch by Petar Jovanovic.
llvm-svn: 169174
|
| |
|
|
|
|
|
| |
This simplifies the hinting code quite a bit while making the targets
easier to write at the same time.
llvm-svn: 169173
|
| |
|
|
| |
llvm-svn: 169172
|
| |
|
|
| |
llvm-svn: 169171
|
| |
|
|
|
|
|
| |
This provides the same functionality as getRawAllocationOrder() for the
even/odd hints, but without the many constant register arrays.
llvm-svn: 169169
|
| |
|
|
|
|
| |
using multiclass.
llvm-svn: 169168
|
| |
|
|
| |
llvm-svn: 169167
|
| |
|
|
| |
llvm-svn: 169166
|
| |
|
|
|
|
|
|
| |
"Windows.h" includes <Windows.h> which defines a bunch of stuff it shouldn't
(even with all the restriction macros). We have no control over this file, so
make it's scope as small as possible.
llvm-svn: 169165
|
| |
|
|
|
|
|
|
| |
unreachable code in MachineModuleInfo
reviewed by Evan Cheng <evan.cheng@apple.com>
llvm-svn: 169164
|
| |
|
|
|
|
| |
"single basic block loop vectorizer" to "innermost loop vectorizer".
llvm-svn: 169158
|
| |
|
|
|
|
| |
space. SmallVector is still needed due to existing APIs growing their arguments
llvm-svn: 169157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
using multiclass.
llvm-svn: 169153
|
| |
|
|
|
|
|
|
| |
which is the legality of the if-conversion transformation. The next step is to
implement the cost-model for the if-converted code as well as the
vectorization itself.
llvm-svn: 169152
|
| |
|
|
| |
llvm-svn: 169149
|
| |
|
|
|
|
| |
HexagonOperards.td.
llvm-svn: 169148
|
| |
|
|
| |
llvm-svn: 169145
|
| |
|
|
| |
llvm-svn: 169143
|
| |
|
|
|
|
| |
Thanks Eric for the review.
llvm-svn: 169142
|
| |
|
|
|
|
| |
calculating the cost after passing the threshold.
llvm-svn: 169135
|
| |
|
|
|
|
| |
pass instance."
llvm-svn: 169134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The partitioning logic attempted to handle uses of an alloca with an
offset starting before the alloca so long as the use had some overlap
with the alloca itself. However, there was a bug where we tested
'(uint64_t)Offset >= AllocSize' without first checking whether 'Offset'
was positive. As a consequence, essentially every negative offset (that
is, starting *before* the alloca does) would be thrown out, even if it
was overlapping. The subsequent code to throw out negative offsets which
were actually non-overlapping was essentially dead. The code to *handle*
overlapping negative offsets was actually dead!
I've just removed all of this, and taught SROA to discard any uses which
start prior to the alloca from the beginning. It has the lovely property
of simplifying the code. =] All the tests still pass, and in fact no new
tests are needed as this is already covered by our testsuite. Fixing the
code so that negative offsets work the way the comments indicate they
were supposed to work causes regressions. That's how I found this.
Anyways, this is all progress in the correct direction -- tightening up
SROA to be maximally aggressive. Some day, I really hope to turn
out-of-bounds accesses to an alloca into 'unreachable'.
llvm-svn: 169120
|
| |
|
|
| |
llvm-svn: 169119
|
| |
|
|
| |
llvm-svn: 169117
|
| |
|
|
| |
llvm-svn: 169111
|
| |
|
|
|
|
|
|
|
|
| |
integer type.
Fixes PR14465.
Differential Revision: http://llvm-reviews.chandlerc.com/D148
llvm-svn: 169084
|
| |
|
|
|
|
| |
status.
llvm-svn: 169083
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also check in a case to repeat the issue, on which 'opt -globalopt' consumes 1.6GB memory.
The big memory footprint cause is that current GlobalOpt one by one hoists and stores the leaf element constant into the global array, in each iteration, it recreates the global array initializer constant and leave the old initializer alone. This may result in many obsolete constants left.
For example: we have global array @rom = global [16 x i32] zeroinitializer
After the first element value is hoisted and installed: @rom = global [16 x i32] [ 1, 0, 0, ... ]
After the second element value is installed: @rom = global [16 x 32] [ 1, 2, 0, 0, ... ] // here the previous initializer is obsolete
...
When the transform is done, we have 15 obsolete initializers left useless.
llvm-svn: 169079
|
| |
|
|
|
|
|
| |
2012-11-30-misched-dbg.ll had crashed. Then (MDNode)N was "!{}".
I am not sure it would be ill-formed or not.
llvm-svn: 169074
|
| |
|
|
|
|
|
|
| |
- Each macro instantiation introduces a new buffer, and FindBufferForLoc() is
linear, so previously macro instantiation could be N^2 for some pathological
inputs.
llvm-svn: 169073
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 169056
|
| |
|
|
|
|
| |
nested ifs
llvm-svn: 169049
|
| |
|
|
| |
llvm-svn: 169048
|
| |
|
|
|
|
|
|
|
|
|
| |
uses. APFloat::convert() takes the pointer to the fltSemantics
variable, which is later accessed it in ~APFloat() desctructor.
That is, semantics must still be alive at the moment we delete
APFloat.
Found by experimental AddressSanitizer use-after-scope checker.
llvm-svn: 169047
|
| |
|
|
|
|
|
|
|
|
|
| |
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: 169043
|
| |
|
|
|
|
|
| |
This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.
llvm-svn: 169039
|
| |
|
|
|
|
| |
reviewed by Michael Ilseman <milseman@apple.com>
llvm-svn: 169025
|