| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
rdar://11096639
llvm-svn: 153269
|
| |
|
|
| |
llvm-svn: 153267
|
| |
|
|
|
|
|
| |
Keep the public interface clean, even though LLVM proper does not
currently use it.
llvm-svn: 153263
|
| |
|
|
| |
llvm-svn: 153262
|
| |
|
|
| |
llvm-svn: 153260
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 153245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
| |
|
|
|
|
|
|
| |
offsets. Fixes PR12203.
I don't have a small test case yet, but I'll try to construct one.
llvm-svn: 153240
|
| |
|
|
| |
llvm-svn: 153238
|
| |
|
|
| |
llvm-svn: 153237
|
| |
|
|
|
|
|
|
|
| |
metadata operand as an actual operand, leading to an assert. Error
out in this case.
rdar://11007633
llvm-svn: 153234
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
som inputs.
Bug found and fix proposed by Kal Conley!
llvm-svn: 153225
|
| |
|
|
|
|
| |
Added ExecutionEngine/MCJIT tests.
llvm-svn: 153221
|
| |
|
|
|
|
| |
case for all opcodes handed by DecodeVSTInstruction() in ARMDisassembler.cpp .
llvm-svn: 153218
|
| |
|
|
| |
llvm-svn: 153208
|
| |
|
|
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120305/138477.html
1. Declare a virtual function getPointerToNamedFunction() in JITMemoryManager
2. Move the implementation of getPointerToNamedFunction() form JIT/MCJIT to DefaultJITMemoryManager.
llvm-svn: 153205
|
| |
|
|
|
|
|
|
| |
Type legalization can zero-extend the elements of the build_vector node, so,
for example, we may have an <8 x i8> with i32 elements of value 255. That
should return 'true' for the vector being all ones.
llvm-svn: 153203
|
| |
|
|
| |
llvm-svn: 153189
|
| |
|
|
| |
llvm-svn: 153185
|
| |
|
|
| |
llvm-svn: 153184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not attched to a basic block or function. There are conservatively
correct answers in these cases, and this makes the analysis more useful
in contexts where we have a partially formed bit of IR.
I don't have any way to test this directly... suggestions welcome here,
but I'm not seeing anything sadly. I only found this using a subsequent
patch to the inliner which runs instsimplify on partially inlined
instructions, and even then only on a quite large program. I never got
a reasonable testcase out of it, and anything I do get is likely to be
quite fragile due to requiring an interaction of two different passes,
and the only result being a segfault if it goes wrong.
llvm-svn: 153176
|
| |
|
|
|
|
|
| |
the invalid cases. At least 16bit operand in 64bit mode is currently not
rejected in the parser.
llvm-svn: 153166
|
| |
|
|
| |
llvm-svn: 153162
|
| |
|
|
| |
llvm-svn: 153161
|
| |
|
|
| |
llvm-svn: 153160
|
| |
|
|
| |
llvm-svn: 153159
|
| |
|
|
| |
llvm-svn: 153158
|
| |
|
|
| |
llvm-svn: 153155
|
| |
|
|
|
|
| |
shuffle elements for consistency with other shuffle code in X86 backend.
llvm-svn: 153154
|
| |
|
|
|
|
|
|
| |
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: 153150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocations (i.e., pieces of data whose addresses
are referred to elsewhere in the binary image) and
update the references when the section containing
the relocations moves. The way this works is that
there is a map from section IDs to lists of
relocations.
Because the relocations are associated with the
section containing the data being referred to, they
are updated only when the target moves. However,
many data references are relative and also depend
on the location of the referrer.
To solve this problem, I introduced a new data
structure, Referrer, which simply contains the
section being referred to and the index of the
relocation in that section. These referrers are
associated with the source containing the
reference that needs to be updated, so now
regardless of which end of the relocation moves,
the relocation will now be updated correctly.
llvm-svn: 153147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 153136
|
| |
|
|
|
|
| |
t2PseudoExpand.
llvm-svn: 153135
|
| |
|
|
|
|
|
|
| |
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: 153133
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 153116
|
| |
|
|
|
|
| |
precedence over the VINSERTF128 avx1 patterns.
llvm-svn: 153114
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ARMBaseRegisterInfo::canRealignStack was checking for variable-sized objects
but not for stack adjustments around calls. Use hasReservedCallFrame() to
check for both. The hasBasePointer function was already correctly checking
both conditions, so the effect of this was that a base pointer would be used
without checking whether the base pointer register could be reserved. I don't
have a small testcase for this.
<rdar://problem/11075906>
llvm-svn: 153110
|
| |
|
|
|
|
|
| |
ARMFrameLowering::hasReservedCallFrame is already checking for variable
sized objects, so there's no point in checking it twice.
llvm-svn: 153109
|
| |
|
|
| |
llvm-svn: 153105
|
| |
|
|
|
|
| |
whitespace from test case. No functional change intended.
llvm-svn: 153103
|