| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 153353
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
llvm-svn: 153351
|
| |
|
|
|
|
| |
No functional change, just tidy up the code and nomenclature a bit.
llvm-svn: 153347
|
| |
|
|
|
|
|
| |
Dump the hex representation to the comment stream as well as the float
value.
llvm-svn: 153346
|
| |
|
|
|
|
| |
entries in the relocation table before they are written out to the file.
llvm-svn: 153345
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
TargetMachine that is created as part of selecting the appropriate target.
This is necessary if the client wants to be able to mutate TargetOptions (for example, fast FP math mode) after the initial creation of the ExecutionEngine.
llvm-svn: 153342
|
| |
|
|
| |
llvm-svn: 153341
|
| |
|
|
|
|
| |
through StringExtras.h
llvm-svn: 153328
|
| |
|
|
|
|
| |
New code should use raw_ostream.
llvm-svn: 153326
|
| |
|
|
|
|
|
|
| |
dominated by Root, check that B is available throughout the scope. This
is obviously true (famous last words?) given the current logic, but the
check may be helpful if more complicated reasoning is added one day.
llvm-svn: 153323
|
| |
|
|
| |
llvm-svn: 153322
|
| |
|
|
| |
llvm-svn: 153315
|
| |
|
|
| |
llvm-svn: 153314
|
| |
|
|
|
|
| |
of memory during LTO.
llvm-svn: 153313
|
| |
|
|
| |
llvm-svn: 153307
|
| |
|
|
| |
llvm-svn: 153306
|
| |
|
|
|
|
|
| |
the PassManager annoying and should be reimplemented as a decorator
on top of existing passes (as should the timing data).
llvm-svn: 153305
|
| |
|
|
| |
llvm-svn: 153287
|
| |
|
|
|
|
| |
Tests cases have been removed but attached to open PR12330.
llvm-svn: 153286
|
| |
|
|
| |
llvm-svn: 153278
|
| |
|
|
| |
llvm-svn: 153277
|
| |
|
|
|
|
|
|
| |
few comments where none existed before. Also change a function's name to match
the current coding standard.
No functionality change.
llvm-svn: 153276
|
| |
|
|
|
|
| |
rdar://11096639
llvm-svn: 153270
|
| |
|
|
|
|
| |
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
|