| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.
Differential Revision: http://reviews.llvm.org/D19035
llvm-svn: 266145
|
|
|
|
| |
llvm-svn: 266144
|
|
|
|
| |
llvm-svn: 266143
|
|
|
|
|
|
| |
And rearrange InitLibcallNames slightly.
llvm-svn: 266142
|
|
|
|
|
|
|
| |
It now documents how we currently handle relocations for
alloc/non-alloc.
llvm-svn: 266141
|
|
|
|
|
|
| |
Suggested by: David Blaikie!
llvm-svn: 266140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specify the demangled name. So all of the following now work:
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
|
|
|
|
|
|
| |
accepting them, and fail to add any strings that fail parsing
llvm-svn: 266138
|
|
|
|
| |
llvm-svn: 266137
|
|
|
|
| |
llvm-svn: 266136
|
|
|
|
| |
llvm-svn: 266135
|
|
|
|
|
|
| |
Suggested by Rafael as post-commit review (r266102).
llvm-svn: 266134
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18748
llvm-svn: 266133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For correct handling of alias to nameless
function, we need to be able to refer them through a GUID in the summary.
Here we name them using a hash of the non-private global names in the module.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18883
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Let keep llvm-as "dumb": it converts textual IR to bitcode. This
commit removes the dependency from llvm-as to libLLVMAnalysis.
We'll add back summary in llvm-as if we get to a textual
representation for it at some point. In the meantime, opt seems
like a better place for that.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19032
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266131
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two use-after-frees in selectLEA64_32Addr. If matchAddress
matches an ADD with an AND as an operand, and that AND hits one of the
"heroic transforms" that folds masks and shifts, we end up with N
pointing to an SDNode that was deleted. Make sure we're done accessing
it before that.
Found by ASan with the recycling allocator changes in llvm.org/PR26808.
llvm-svn: 266130
|
|
|
|
|
|
| |
the real way to invoke it
llvm-svn: 266129
|
|
|
|
|
|
| |
Same effect, easier to read.
llvm-svn: 266128
|
|
|
|
|
|
| |
any time so n
llvm-svn: 266127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
They correspond to BUFFER_LOAD/STORE_DWORD[_X2,X3,X4] and mostly behave like
llvm.amdgcn.buffer.load/store.format. They will be used by Mesa for SSBO and
atomic counters at least when robust buffer access behavior is desired.
(These instructions perform no format conversion and do buffer range checking
per component.)
As a side effect of sharing patterns with llvm.amdgcn.buffer.store.format,
it has become trivial to add support for the f32 and v2f32 variants of that
intrinsic, so the patch does so.
Also DAG-ify (and fix) some tests that I noticed intermittent failures in
while developing this patch.
Some tests were (temporarily) adjusted for the required mayLoad/hasSideEffects
changes to the BUFFER_STORE_DWORD* instructions. See also
http://reviews.llvm.org/D18291.
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18292
llvm-svn: 266126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The function import pass was computing all the imports for all the
modules in the index, and only using the imports for the current module.
Change this to instead compute only for the given module. This means
that the exports list can't be populated, but they weren't being used
anyway.
Longer term, the linker can collect all the imports and export lists
and serialize them out for consumption by the distributed backend
processes which use this pass.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18945
llvm-svn: 266125
|
|
|
|
|
|
| |
They are wordy. Some words were wrong.
llvm-svn: 266124
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and is expected to
use it more widely in the future), and it requires the EH frame segment
in static binaries.
This is the same as r203742 for NetBSD.
Differential Revision: http://reviews.llvm.org/D19029
llvm-svn: 266123
|
|
|
|
|
|
| |
Patch by Jing Yu!
llvm-svn: 266122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility.
These symbols describe a property of a linkage unit, so it seems reasonable
to limit their visibility to the linkage unit. Furthermore the use cases I
am aware of do not require more than hidden visibility.
This is a departure from the behavior of the bfd and gold linkers. However,
it is unclear that the decision to give these symbols default visibility
in those linkers was made deliberately. The __start_*/__stop_* feature
was added to the bfd linker in 1994 [1], while the visibility feature was
added about five years later [2], so it may have been that the visibility
of these symbols was not considered. The feature was implemented in gold
[3] in the same way; the behavior may have simply been copied from bfd.
The only related discussion I could find on the binutils mailing list [4]
was a user issue which would most likely not have occurred if the symbols
had hidden visibility.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b
[2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca
[3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c
[4] https://sourceware.org/ml/binutils/2014-05/msg00011.html
Differential Revision: http://reviews.llvm.org/D19024
llvm-svn: 266121
|
|
|
|
|
|
| |
All these routines are implemented in the offload library.
llvm-svn: 266120
|
|
|
|
|
|
| |
calculation. NFC.
llvm-svn: 266119
|
|
|
|
|
|
|
|
| |
checked in that is now reverted.
<rdar://problem/25643874>
llvm-svn: 266118
|
|
|
|
|
|
|
|
| |
Clang should pass -backend-option to LLVM even though there is no target machine, since LLVM passes are used when emitting LLVM IR.
Differential Revision: http://reviews.llvm.org/D17552
llvm-svn: 266117
|
|
|
|
| |
llvm-svn: 266116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Recommit of r266002, with r266011, r266016, and not accidentally
including an extra unused/uninitialized element in LibcallRoutineNames)
AtomicExpandPass can now lower atomic load, atomic store, atomicrmw, and
cmpxchg instructions to __atomic_* library calls, when the target
doesn't support atomics of a given size.
This is the first step towards moving all atomic lowering from clang
into llvm. When all is done, the behavior of __sync_* builtins,
__atomic_* builtins, and C11 atomics will be unified.
Previously LLVM would pass everything through to the ISelLowering
code. There, unsupported atomic instructions would turn into __sync_*
library calls. Because of that behavior, Clang currently avoids emitting
llvm IR atomic instructions when this would happen, and emits __atomic_*
library functions itself, in the frontend.
This change makes LLVM able to emit __atomic_* libcalls, and thus will
eventually allow clang to depend on LLVM to do the right thing.
It is advantageous to do the new lowering to atomic libcalls in
AtomicExpandPass, before ISel time, because it's important that all
atomic operations for a given size either lower to __atomic_*
libcalls (which may use locks), or native instructions which won't. No
mixing and matching.
At the moment, this code is enabled only for SPARC, as a
demonstration. The next commit will expand support to all of the other
targets.
Differential Revision: http://reviews.llvm.org/D18200
llvm-svn: 266115
|
|
|
|
|
|
| |
It lacked a CU and thus became invalid with r266102
llvm-svn: 266114
|
|
|
|
|
|
|
|
| |
and we fall back to textual inclusion, don't require the module as a whole to
be marked available; it's OK if some other file in the same module is missing,
just as it would be if the header were explicitly marked textual.
llvm-svn: 266113
|
|
|
|
|
|
| |
The patch doesn't apply, and was removed from zorg by rL266094.
llvm-svn: 266112
|
|
|
|
|
|
|
|
|
|
|
|
| |
ternary operator.
Generates addrspacecast instead of bitcast for ternary operator when necessary, and diagnose ternary operator with incompatible second and third operands.
https://llvm.org/bugs/show_bug.cgi?id=19957
Differential Revision: http://reviews.llvm.org/D17412
llvm-svn: 266111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The nullability checker can sometimes miss detecting nullability precondition
violations in inlined functions because the binding for the parameter
that violated the precondition becomes dead before the return:
int * _Nonnull callee(int * _Nonnull p2) {
if (!p2)
// p2 becomes dead here, so binding removed.
return 0; // warning here because value stored in p2 is symbolic.
else
return p2;
}
int *caller(int * _Nonnull p1) {
return callee(p1);
}
The fix, which is quite blunt, is to not warn about null returns in inlined
methods/functions. This won’t lose much coverage for ObjC because the analyzer
always analyzes each ObjC method at the top level in addition to inlined. It
*will* lose coverage for C — but there aren’t that many codebases with C
nullability annotations.
rdar://problem/25615050
llvm-svn: 266109
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r260990 exposed -isystem in clang-cl. -isystem adds a directory to the front of
the system include search path. The idea was to use this to point to a hermetic
msvc install, but as it turns out this doesn't work: -isystem then adds the
hermetic headers in front of clang's builtin headers, and clang's headers that
are supposed to wrap msvc headers (say, stdarg.h) aren't picked up at all
anymore.
So revert that, and instead expose -imsvc which works as if the passed
directory was part of %INCLUDE%: The header is treated as a system header, but
it is searched after clang's lib/Header headers.
Fixes half of PRPR26751.
llvm-svn: 266108
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change.
In codegen different address spaces may be mapped to the same address
space for a target, e.g. in x86/x86-64 all address spaces are mapped
to 0. Therefore AddressSpaceConversion should be translated by
CreatePointerBitCastOrAddrSpaceCast instead of CreateAddrSpaceCast.
Differential Revision: http://reviews.llvm.org/D18713
llvm-svn: 266107
|
|
|
|
|
|
|
| |
Disable FORTIFY_SOURCE and explicitly disable stack protector in the
no-stack-protector run.
llvm-svn: 266106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We will be able to handle this case much better once the hazard recognizer
is finished, but this conservative implementation fixes a hang with the piglit
test:
spec/arb_arrays_of_arrays/execution/sampler/fs-nested-struct-arrays-nonconst-nested-arra
Reviewers: arsenm, nhaehnle
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18988
llvm-svn: 266105
|
|
|
|
|
|
|
|
|
|
| |
This helps clean up some of the mess when expanding unaligned 64-bit
loads when changed to be promote to v2i32, and fixes situations
where or x, 0 was emitted after splitting 64-bit ors during moveToVALU.
I think this could be a generic combine but I'm not sure.
llvm-svn: 266104
|
|
|
|
|
|
| |
This time it should also pass the gtests
llvm-svn: 266103
|
|
|
|
|
|
|
|
|
|
|
| |
Add a check to catch violations. ~60 tests were broken and prevented
this change to be committed. Adrian and I (thanks Adrian!) went
through them in the last week or so updating. The check can be
done more efficiently but I'd still like to get this in ASAP to
avoid more broken tests to be checked in (if any).
PR: 27101
llvm-svn: 266102
|
|
|
|
|
|
|
| |
This mimics the version in MathExtras.h which isn't testing for a
specific mask size.
llvm-svn: 266101
|
|
|
|
|
|
|
|
|
|
|
| |
This code was specific to vector operations with scalar operands:
all the opcodes in FoldValue (via FoldConstantArithmetic) can't
match those criteria.
Replace it with an assert if that ever changes: at that point,
we might need to add back a splat BUILD_VECTOR.
llvm-svn: 266100
|
|
|
|
|
|
| |
Following up to a similar fix in MergeFunctions: r266022. This patch keeps both in sync, it would be nice to not have to do this. It doesn't look like there's an easy way to test this code directly at the moment: AFAICT all currect uses of isSameOperationAs are looking at instructions deep inside a function. IndVarSimplify/pr24952.ll and InstMerge/st_sink_* look at alloca inadvertently but are brittle tests.
llvm-svn: 266099
|
|
|
|
|
|
| |
Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor simplifications and code sharing.
llvm-svn: 266098
|
|
|
|
| |
llvm-svn: 266097
|
|
|
|
| |
llvm-svn: 266096
|
|
|
|
| |
llvm-svn: 266095
|