| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
For example, LLVMSupport takes the form of LLVMSupport.dll, not libLLVMSupport.dll.
llvm-svn: 260351
|
|
|
|
|
|
|
|
| |
timestamps.
Duh! With this change I've verified -O3 builds are deterministic.
llvm-svn: 260350
|
|
|
|
|
|
|
|
|
|
| |
the value being cast to return a Python number with the proper value
The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless
Fixes rdar://24556976
llvm-svn: 260349
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17062
llvm-svn: 260348
|
|
|
|
|
|
| |
msvc.
llvm-svn: 260347
|
|
|
|
|
|
| |
Suggested by Paul Robinson.
llvm-svn: 260346
|
|
|
|
| |
llvm-svn: 260345
|
|
|
|
|
|
| |
I guess it would be working since Rafael's r187619.
llvm-svn: 260344
|
|
|
|
|
|
|
| |
and target. It has been there since r252532.
FIXME: The clause may use conditions of host compiler, not HOST_TRIPLE.
llvm-svn: 260343
|
|
|
|
|
|
| |
This should fix some random bot failures caused by r260336.
llvm-svn: 260342
|
|
|
|
|
|
| |
For multi-stage builds we need to pass any overridden source directory variables. Without passing these the subsequent stages won't find the project sources.
llvm-svn: 260341
|
|
|
|
|
|
|
|
| |
I had hoped this would work from a single cache file, but turns out there is a bug I can't quite figure out relating to passing list arguments to recursive CMake invocations.
This change works around that.
llvm-svn: 260340
|
|
|
|
|
|
| |
This reverts r260262, it broke some LLVM tests (bugpoint).
llvm-svn: 260339
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new class, OrcI386, which contains the hooks needed to
support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT
re-entry code uses the FXSAVE/FXRSTOR instructions).
Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and
regression and unit tests are enabled for this architecture.
llvm-svn: 260338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<string.h> and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from <wchar.h> to
provide a const-correct overload set even when the underlying C library does
not.
This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined)
specifies that a given overload is a better match than an otherwise equally
good function declaration without the overload. This is implemented in modern
versions of Clang via __attribute__((enable_if)), and not elsewhere.
We use this new macro to define overloads in the global namespace for these
functions that displace the overloads provided by the C library, unless we
believe the C library is already providing the correct signatures.
llvm-svn: 260337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Tests for this will be added once the AMDGPU backend enables this
option.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16602
llvm-svn: 260336
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. This also include extra support for insertvalue and extracvalue.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17055
llvm-svn: 260335
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This isn't a FileCheck directive; it does nothing.
Reviewers: jroelofs
Subscribers: cfe-commits, majnemer
Differential Revision: http://reviews.llvm.org/D17051
llvm-svn: 260334
|
|
|
|
|
|
|
|
| |
f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.
Differential Revision: http://reviews.llvm.org/D17021
llvm-svn: 260333
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction from the C API.
Summary: As per title. This remove the need to rely on internal knowledge of call and invoke instruction to find called value and argument count.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Differential Revision: http://reviews.llvm.org/D17054
llvm-svn: 260332
|
|
|
|
| |
llvm-svn: 260331
|
|
|
|
|
|
|
|
|
|
| |
CFLAGS is now being set correctly to pass -flimit-debug-info or
-fno-limit-debug-info on FreeBSD. I'm not sure which change is
responsible for the fix, though.
llvm.org/pr25626
llvm-svn: 260330
|
|
|
|
|
|
|
|
| |
It seems the ARMv8 instruction set overview is no longer provided by ARM, so
I've removed it. Since most of the other documents were the same I unified the
two sections.
llvm-svn: 260329
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16902
llvm-svn: 260328
|
|
|
|
| |
llvm-svn: 260327
|
|
|
|
|
|
|
| |
lld was already using a target named CoreTests so CMake
was erroring due to this conflict.
llvm-svn: 260326
|
|
|
|
|
|
|
| |
This is the load counterpart to the store optimization that was added in:
http://reviews.llvm.org/rL260145
llvm-svn: 260325
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is a bit of refactoring required to be able to generate instruction in forward basic block. This, for instance, is a requirement for phi in loops.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Differential Revision: http://reviews.llvm.org/D17050
llvm-svn: 260324
|
|
|
|
|
|
|
|
|
|
|
| |
libatomic."
This reverts commit r260235. It breaks LLVM's bootstrap when building
with a -gcc-toolchain and the system's gcc installation does not provide
the libatomic library and its headers. We should check whether
LIBCXX_GCC_TOOLCHAIN is set and adjust the flags accordingly.
llvm-svn: 260323
|
|
|
|
|
|
|
|
|
| |
functions from being added to class definitions (see revision 260308 for details).
<rdar://problem/24483905>
<rdar://problem/24508374>
llvm-svn: 260322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Improving coverage.
Depends on D16912 .
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16937
llvm-svn: 260321
|
|
|
|
| |
llvm-svn: 260320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove the convergent attribute on any functions which provably do not
contain or invoke any convergent functions.
After this change, we'll be able to modify clang to conservatively add
'convergent' to all functions when compiling CUDA.
Reviewers: jingyue, joker.eph
Subscribers: llvm-commits, tra, jhen, hfinkel, resistor, chandlerc, arsenm
Differential Revision: http://reviews.llvm.org/D17013
llvm-svn: 260319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Be more explicit about what 'convergent' means, and indicate that the
compiler may remove the attribute from a function if it can prove that
the function doesn't in fact execute any convergent ops.
Reviewers: resistor, jingyue, joker.eph
Subscribers: hfinkel, chandlerc, arsenm, jhen, tra, llvm-commits
Differential Revision: http://reviews.llvm.org/D17012
llvm-svn: 260318
|
|
|
|
| |
llvm-svn: 260317
|
|
|
|
| |
llvm-svn: 260316
|
|
|
|
|
|
|
| |
Using Op makes it look like we're doing something with it.
We're really not.
llvm-svn: 260315
|
|
|
|
| |
llvm-svn: 260314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Comes with an awesome test.
Depends on D16912
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16942
llvm-svn: 260313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass implements whole program optimization of virtual calls in cases
where we know (via bitset information) that the list of callees is fixed. This
includes the following:
- Single implementation devirtualization: if a virtual call has a single
possible callee, replace all calls with a direct call to that callee.
- Virtual constant propagation: if the virtual function's return type is an
integer <=64 bits and all possible callees are readnone, for each class and
each list of constant arguments: evaluate the function, store the return
value alongside the virtual table, and rewrite each virtual call as a load
from the virtual table.
- Uniform return value optimization: if the conditions for virtual constant
propagation hold and each function returns the same constant value, replace
each virtual call with that constant.
- Unique return value optimization for i1 return values: if the conditions
for virtual constant propagation hold and a single vtable's function
returns 0, or a single vtable's function returns 1, replace each virtual
call with a comparison of the vptr against that vtable's address.
Differential Revision: http://reviews.llvm.org/D16795
llvm-svn: 260312
|
|
|
|
|
|
| |
(and has for quite a while). Also document that we have not yet implemented the new inheriting constructor rules.
llvm-svn: 260311
|
|
|
|
| |
llvm-svn: 260310
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. Also add a facility method to get the name of a basic block from the C API.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16912
llvm-svn: 260309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
up when parsing expressions.
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:
class A
{
<template T>
void Foo(T t);
};
The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
class A
{
void Foo(int t);
void Foo(double t);
};
And a version from b.cpp that used a "float" overload to look like:
class A
{
void Foo(float t);
};
And a version from c.cpp that use no overloads to look like:
class A
{
};
Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug:
<rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext.
So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
class A
{
};
And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
<rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
before we can do anything about it in LLDB.
This bug mainly fixed the following Apple radar:
<rdar://problem/24483905>
llvm-svn: 260308
|
|
|
|
|
|
| |
of digit separators.
llvm-svn: 260307
|
|
|
|
|
|
|
| |
The problem is that the master's thread state was not saved before entering a
parallel region so it does not remember tasks when it returns.
llvm-svn: 260306
|
|
|
|
|
|
|
|
|
| |
Now the parser supports `%got(sym)` expressions only but `%got(sym + const)`
variant is also valid and accepted by GAS.
Differential Revision: http://reviews.llvm.org/D16885
llvm-svn: 260305
|
|
|
|
|
|
|
|
| |
we require llvm 3.7
reviewer: tstellard
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 260304
|
|
|
|
|
|
|
|
|
| |
Also remove definitions if provided by clang (3.7+)
This halves the size of builtin.opt.{cedar,barts}.bc
reviewer: tstellard
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 260303
|
|
|
|
|
|
|
|
|
|
|
| |
Make cl_khr_fp64 define per-device.
This patch does not change the generated Makefile (for llvm 3.6, 3.7)
v2: Make the device defines per LLVM version, 'all' for all versions
reviewer: tstellard
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 260302
|