| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
I'll implement error handling and a negative test in both llvm-mc and
Clang soon.
llvm-svn: 205016
|
| |
|
|
|
|
|
|
|
| |
If --allow-multiple-definition option is given, LLD does not treat duplicate
symbol error as a fatal error. GNU LD supports this option.
Differential Revision: http://llvm-reviews.chandlerc.com/D3211
llvm-svn: 205015
|
| |
|
|
| |
llvm-svn: 205014
|
| |
|
|
| |
llvm-svn: 205013
|
| |
|
|
| |
llvm-svn: 205012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A \
int i; /*a*/ \
int jjj; /*b*/
After:
#define A \
int i; /*a*/ \
int jjj; /*b*/
llvm-svn: 205011
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r204912, and follow-up commit r204948.
This introduced a performance regression, and the fix is not completely
clear yet.
llvm-svn: 205010
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r203553, and follow-up commits r203558 and r203574.
I will follow this up on the mailinglist to do it in a way that won't
cause subtle PRE bugs.
llvm-svn: 205009
|
| |
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3096
llvm-svn: 205008
|
| |
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3095
llvm-svn: 205007
|
| |
|
|
| |
llvm-svn: 205006
|
| |
|
|
|
|
|
|
| |
This was causing my llc to go into an infinite loop on
CodeGen/R600/address-space.ll (just triggered recently by some allocator
changes).
llvm-svn: 205005
|
| |
|
|
|
|
|
|
| |
These interceptors require deep unpoisoning of return values.
While at it, we do the same for all other pw/gr interceptors to
reduce dependency on libc implementation details.
llvm-svn: 205004
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These are used in the ARM backends to aid type-checking on patterns involving
intrinsics. By making sure one argument is an extended/truncated version of
another.
However, there's no reason to limit them to just vectors types. For example
AArch64 has the instruction "uqshrn sD, dN, #imm" which would naturally use an
intrinsic taking an i64 and returning an i32.
llvm-svn: 205003
|
| |
|
|
|
|
|
|
| |
It's hard to write a reliable test for this code because they
work with unpredictable memory locations. But this change should
fix current failures in getpwent() tests on the sanitizer bots.
llvm-svn: 205002
|
| |
|
|
| |
llvm-svn: 205001
|
| |
|
|
| |
llvm-svn: 205000
|
| |
|
|
|
|
|
|
| |
Based on patch from GuanHong Liu.
Differential Revision: http://llvm-reviews.chandlerc.com/D2796
llvm-svn: 204999
|
| |
|
|
| |
llvm-svn: 204998
|
| |
|
|
|
|
| |
We don't want to deviate from clang's standard terminology.
llvm-svn: 204997
|
| |
|
|
|
|
|
|
|
| |
bottom of the interface to make it easier to scan and find the public
API.
No functionality changed.
llvm-svn: 204996
|
| |
|
|
|
|
|
| |
out-of-line private static method and into the collection of inline
alignment helpers in MathExtras.h.
llvm-svn: 204995
|
| |
|
|
| |
llvm-svn: 204994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a recurrance. I *think* the previous behavior was essentially that the
size of the slabs would be doubled after the first 128 were allocated,
and then doubled again each time 64 more were allocated, but only if
every allocation packed perfectly into the slab size. If not, the wasted
space wouldn't be counted toward increasing the size, but allocations
over the size threshold *would*. And since the allocations over the size
threshold might be much larger than the slab size, this could have
somewhat surprising consequences where we rapidly grow the slab size.
This currently requires adding state to the allocator to track the
number of slabs currently allocated, but that isn't too bad. I'm
planning further changes to the allocator that will make this state fall
out even more naturally.
It still doesn't fully decouple the growth rate from the allocations
which are over the size threshold. That fix is coming later.
This specific fix will allow making the entire thing into a more
stateless device and lifting the parameters into template parameters
rather than runtime parameters.
llvm-svn: 204993
|
| |
|
|
|
|
|
|
| |
top of the default jit memory manager. This will allow them to be used
as template parameters rather than runtime parameters in a subsequent
commit.
llvm-svn: 204992
|
| |
|
|
| |
llvm-svn: 204991
|
| |
|
|
| |
llvm-svn: 204990
|
| |
|
|
| |
llvm-svn: 204989
|
| |
|
|
|
|
|
| |
These classes are declared in a .cpp file but not used in the same compliation
unit. They seems to have been copy-and-pasted from ELFReader.h.
llvm-svn: 204988
|
| |
|
|
| |
llvm-svn: 204987
|
| |
|
|
| |
llvm-svn: 204986
|
| |
|
|
|
|
|
| |
This should fix the clang-cl tests after the Windows target triple
canonicalization (r204978)
llvm-svn: 204985
|
| |
|
|
| |
llvm-svn: 204984
|
| |
|
|
|
|
|
|
|
| |
* Use assignment instead of swap (since the original value is being
destroyed anyway)
* Rename "updateAdjEdgeId" to "setAdjEdgeId"
llvm-svn: 204983
|
| |
|
|
| |
llvm-svn: 204982
|
| |
|
|
| |
llvm-svn: 204981
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As explained in r204976, because of how the allocation of VSX registers
interacts with the call-lowering code, we sometimes end up generating self VSX
copies. Specifically, things like this:
%VSL2<def> = COPY %F2, %VSL2<imp-use,kill>
(where %F2 is really a sub-register of %VSL2, and so this copy is a nop)
This adds a small cleanup pass to remove these prior to post-RA scheduling.
llvm-svn: 204980
|
| |
|
|
|
|
|
|
|
| |
for the first time.
Thanks Andy for the discussion.
rdar://16162005
llvm-svn: 204979
|
| |
|
|
|
|
|
|
|
| |
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
llvm-svn: 204977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of how the allocation of VSX registers interacts with the call-lowering
code, we sometimes end up generating self VSX copies. Specifically, things like
this:
%VSL2<def> = COPY %F2, %VSL2<imp-use,kill>
(where %F2 is really a sub-register of %VSL2, and so this copy is a nop)
The problem is that ExpandPostRAPseudos always assumes that *some* instruction
has been inserted, and adds implicit defs to it. This is a problem if no copy
was inserted because it can cause subtle problems during post-RA scheduling.
These self copies will have to be removed some other way.
llvm-svn: 204976
|
| |
|
|
|
|
| |
<rdar://problem/16349536>
llvm-svn: 204975
|
| |
|
|
|
|
| |
results, some still have link errors.
llvm-svn: 204974
|
| |
|
|
|
|
|
| |
This reverts commit r204964 because it disabled "= delete", "constexpr"
and "explicit" on GCC.
llvm-svn: 204973
|
| |
|
|
|
|
|
|
| |
in my previous commit (r204884).
<rdar://problem/16381225>
llvm-svn: 204972
|
| |
|
|
|
|
|
|
|
| |
First, v2f64 vector extract had not been declared legal (and so the existing
patterns were not being used). Second, the patterns for that, and for
scalar_to_vector, should really be a regclass copy, not a subregister
operation, because the VSX registers directly hold both the vector and scalar data.
llvm-svn: 204971
|
| |
|
|
| |
llvm-svn: 204970
|
| |
|
|
| |
llvm-svn: 204969
|
| |
|
|
|
|
| |
with non-MSVC compilers.
llvm-svn: 204968
|
| |
|
|
| |
llvm-svn: 204967
|