| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
instruction simplify that lets us remove an and when loding a boolean value.
llvm-svn: 153423
|
|
|
|
|
|
|
| |
constant-offsets of a common base using the generic GEP-walking logic
I added for computing pointer differences in the same situation.
llvm-svn: 153419
|
|
|
|
|
|
|
|
|
|
|
|
| |
inbounds GEPs. This isn't really necessary for simplifying pointer
differences, but I'm planning to re-use the same code to simplify
pointer comparisons where it is necessary. Since real code almost
exclusively uses inbounds GEPs, it doesn't seem worth it to support the
extra complexity of turning it on and off. If anyone would like that
back, feel free to shout. Note that instcombine will still catch any of
these patterns.
llvm-svn: 153418
|
|
|
|
| |
llvm-svn: 153412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggressively. There are lots of dire warnings about this being expensive
that seem to predate switching to the TrackingVH-based value remapper
that is automatically updated on RAUW. This makes it easy to not just
prune single-entry PHIs, but to fully simplify PHIs, and to recursively
simplify the newly inlined code to propagate PHINode simplifications.
This introduces a bit of a thorny problem though. We may end up
simplifying a branch condition to a constant when we fold PHINodes, and
we would like to nuke any dead blocks resulting from this so that time
isn't wasted continually analyzing them, but this isn't easy. Deleting
basic blocks *after* they are fully cloned and mapped into the new
function currently requires manually updating the value map. The last
piece of the simplification-during-inlining puzzle will require either
switching to WeakVH mappings or some other piece of refactoring. I've
left a FIXME in the testcase about this.
llvm-svn: 153410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Removed test/lib/llvm.exp - it is no longer needed
* Deleted the dg.exp reading code from test/lit.cfg. There are no dg.exp files
left in the test suite so this code is no longer required. test/lit.cfg is
now much shorter and clearer
* Removed a lot of duplicate code in lit.local.cfg files that need access to
the root configuration, by adding a "root" attribute to the TestingConfig
object. This attribute is dynamically computed to provide the same
information as was previously provided by the custom getRoot functions.
* Documented the config.root attribute in docs/CommandGuide/lit.pod
llvm-svn: 153408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to instead rely on much more generic and powerful instruction
simplification in the function cloner (and thus inliner).
This teaches the pruning function cloner to use instsimplify rather than
just the constant folder to fold values during cloning. This can
simplify a large number of things that constant folding alone cannot
begin to touch. For example, it will realize that 'or' and 'and'
instructions with certain constant operands actually become constants
regardless of what their other operand is. It also can thread back
through the caller to perform simplifications that are only possible by
looking up a few levels. In particular, GEPs and pointer testing tend to
fold much more heavily with this change.
This should (in some cases) have a positive impact on compile times with
optimizations on because the inliner itself will simply avoid cloning
a great deal of code. It already attempted to prune proven-dead code,
but now it will be use the stronger simplifications to prove more code
dead.
llvm-svn: 153403
|
|
|
|
|
|
|
|
| |
regressed seriously here, we are no longer removing allocas during
inline cleanup. This appears to be because of lifetime markers "using"
them. =/ I'll look into this shortly.
llvm-svn: 153394
|
|
|
|
|
|
|
| |
The PPC64 SVR4 ABI requires integer stack arguments, and thus the var. args., that
are smaller than 64 bits be zero extended to 64 bits.
llvm-svn: 153373
|
|
|
|
|
|
| |
metadata.
llvm-svn: 153359
|
|
|
|
|
|
| |
is retaining the return value of an invoke that it immediately follows.
llvm-svn: 153344
|
|
|
|
|
|
|
|
|
|
|
|
| |
same basic block, and it's not safe to insert code in the successor
blocks if the edges are critical edges. Splitting those edges is
possible, but undesirable, especially on the unwind side. Instead,
make the bottom-up code motion to consider invokes to be part of
their successor blocks, rather than part of their parent blocks, so
that it doesn't push code past them and onto the edges. This fixes
PR12307.
llvm-svn: 153343
|
|
|
|
|
|
| |
Tests cases have been removed but attached to open PR12330.
llvm-svn: 153286
|
|
|
|
| |
llvm-svn: 153259
|
|
|
|
| |
llvm-svn: 153258
|
|
|
|
| |
llvm-svn: 153257
|
|
|
|
|
|
| |
canonical indvars.
llvm-svn: 153256
|
|
|
|
| |
llvm-svn: 153255
|
|
|
|
|
|
| |
of the STRD, STRH, LDRD, LDRH, LDRSH and LDRSB instructions on ARM.
llvm-svn: 153252
|
|
|
|
|
|
| |
LDRSHT instruction on ARM
llvm-svn: 153251
|
|
|
|
|
|
| |
ARM.
llvm-svn: 153250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.
The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.
When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.
llvm-svn: 153241
|
|
|
|
|
|
|
|
|
| |
execution-time regression for nsieve-bits on the ARMv7 -O0 -g nightly tester.
This may also improve compile-time on architectures that would otherwise
generate a libcall for urem (e.g., ARM) or fall back to the DAG selector.
rdar://10810716
llvm-svn: 153230
|
|
|
|
| |
llvm-svn: 153222
|
|
|
|
|
|
| |
Added ExecutionEngine/MCJIT tests.
llvm-svn: 153221
|
|
|
|
|
|
| |
case for all opcodes handed by DecodeVSTInstruction() in ARMDisassembler.cpp .
llvm-svn: 153218
|
|
|
|
|
|
|
| |
the invalid cases. At least 16bit operand in 64bit mode is currently not
rejected in the parser.
llvm-svn: 153166
|
|
|
|
| |
llvm-svn: 153165
|
|
|
|
| |
llvm-svn: 153163
|
|
|
|
|
|
|
|
| |
These changes allow us to compile big endian from the command line for 32 bit
Mips targets. This patch will result in code and data actually being produced
in the correct endianess.
llvm-svn: 153153
|
|
|
|
| |
llvm-svn: 153140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vextractf128 with 128-bit mem dest.
Combines
vextractf128 $0, %ymm0, %xmm0
vmovaps %xmm0, (%rdi)
to
vextractf128 $0, %ymm0, (%rdi)
rdar://11082570
llvm-svn: 153139
|
|
|
|
|
|
| |
rdar://11027851
llvm-svn: 153137
|
|
|
|
|
|
|
|
| |
Do not call SplitBlockPredecessors on a loop preheader when one of the
predecessors is an indirectbr. Otherwise, you will hit this assert:
!isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst"
llvm-svn: 153134
|
|
|
|
| |
llvm-svn: 153132
|
|
|
|
|
|
|
|
|
| |
instead of skipping the current loop.
My prior fix was incomplete because of an overzealous compile-time optimization:
Better fix for: <rdar://problem/11049788> Segmentation fault: 11 in LoopStrengthReduce
llvm-svn: 153131
|
|
|
|
|
|
| |
whitespace from test case. No functional change intended.
llvm-svn: 153103
|
|
|
|
| |
llvm-svn: 153099
|
|
|
|
|
|
|
|
| |
Needed when building -mdynamic-no-pic code.
rdar://10459256
llvm-svn: 153097
|
|
|
|
| |
llvm-svn: 153095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This results in things such as
vmovups 16(%rdi), %xmm0
vinsertf128 $1, %xmm0, %ymm0, %ymm0
to be combined to
vinsertf128 $1, 16(%rdi), %ymm0, %ymm0
rdar://11076953
llvm-svn: 153092
|
|
|
|
|
|
| |
register operand is given now fail with soft fail. Modified the regression tests to reflect this.
llvm-svn: 153089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:
0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)
The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>
llvm-svn: 153081
|
|
|
|
|
|
|
| |
Patch by Weiming Zhao!
This fixes PR12212
llvm-svn: 153049
|
|
|
|
| |
llvm-svn: 153038
|
|
|
|
|
|
|
|
|
|
| |
X86InstrCompiler.td.
It also adds –mcpu-generic to the legalize-shift-64.ll test so the test
will pass if run on an Intel Atom CPU, which would otherwise
produce an instruction schedule which differs from that which the test expects.
llvm-svn: 153033
|
|
|
|
|
|
|
|
| |
overflow checking multiply intrinsic as well.
Add a test for this, updating the test from grep to FileCheck.
llvm-svn: 153028
|
|
|
|
|
|
|
|
| |
evaluated to '1' when the argument list was empty (should be '0').
rdar://11057257
llvm-svn: 152967
|
|
|
|
|
|
|
|
|
|
| |
It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.
rdar://11064740
llvm-svn: 152943
|
|
|
|
| |
llvm-svn: 152935
|