| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C++ and C semantics of the compare_and_swap operations actually
require us to return a boolean "success" value. In LLVM terms this
means a second comparison of the output of "cmpxchg" against the input
desired value.
However, x86's "cmpxchg" instruction sets all flags for the comparison
formed, so we can skip any secondary comparison. (N.b. this isn't true
for cmpxchg8b/16b, which only set ZF).
rdar://problem/13201607
llvm-svn: 210523
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
enum Fruit { //
APPLE,
PEAR };
After:
enum Fruit { //
APPLE,
PEAR
};
llvm-svn: 210522
|
|
|
|
| |
llvm-svn: 210521
|
|
|
|
|
|
|
|
|
|
| |
Previously we were abandonning the attempt, leading to some combination of
extra work (when selection of a load/store fails completely) and inferior code
(when this leads to a real memcpy call instead of inlining).
rdar://problem/17187463
llvm-svn: 210520
|
|
|
|
|
|
|
|
|
|
| |
We were hitting an assert if FastISel couldn't create the load or store we
requested. Currently this happens for large frame-local addresses, though
CodeGen could be improved there.
rdar://problem/17187463
llvm-svn: 210519
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
|
|
|
|
| |
llvm-svn: 210517
|
|
|
|
| |
llvm-svn: 210516
|
|
|
|
|
|
|
| |
Doing so would be inconsistent with the common fallback case where backend
diagnostics without source locations are emitted unconditionally.
llvm-svn: 210515
|
|
|
|
|
|
|
|
|
|
| |
Before:
return [ i, args... ]{};
After:
return [i, args...] {};
llvm-svn: 210514
|
|
|
|
|
|
|
| |
With AlwaysSplitBeforeMultilineStrings, clang-format would not find any
valid solution.
llvm-svn: 210513
|
|
|
|
|
|
|
|
|
|
| |
Anyone enabling this warning would expect to hear about all occurrences
including those in system headers that can cause non-reproducible builds.
To achieve this, rework ShowInSystemHeader to remove broken unused mapping code
that didn't make sense with a simpler and correct scheme.
llvm-svn: 210512
|
|
|
|
|
|
|
| |
This GCC warning is useful for validating reproducible builds
and might help when tracking down issues with modules too.
llvm-svn: 210511
|
|
|
|
|
|
|
| |
Make sure grep catches the correct diagnostic, otherwise this test fails to
detect broken functionality.
llvm-svn: 210510
|
|
|
|
|
|
|
|
| |
(section name, section index, full name) into the separate functions.
No functional changes.
llvm-svn: 210509
|
|
|
|
| |
llvm-svn: 210508
|
|
|
|
| |
llvm-svn: 210507
|
|
|
|
|
|
|
| |
In -r mode the sections use the table used to parse .o files. Otherwise
use final exectuable table. No functionality change.
llvm-svn: 210506
|
|
|
|
|
|
|
|
|
| |
instantiation
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.
llvm-svn: 210505
|
|
|
|
|
|
|
|
|
|
|
| |
large types (i64 and above).
This improves the X86 cost model for small constants with large types. Before
this commit we would even hoist trivial constants such as i96 2.
This is related to <rdar://problem/17070936>
llvm-svn: 210504
|
|
|
|
|
|
|
|
|
|
|
| |
GCC-compatible
It turns out the trailing '=' really is part of the option name spelling and
treating it as such gets us compatible with GCC's -Werror= and pragmas.
(GCC doesn't appear to support any -Wno- form for this diagnostic but we do.)
llvm-svn: 210503
|
|
|
|
| |
llvm-svn: 210502
|
|
|
|
|
|
|
|
| |
Reviewered by: rafael
Differential Revision: http://reviews.llvm.org/D4073
llvm-svn: 210501
|
|
|
|
| |
llvm-svn: 210500
|
|
|
|
| |
llvm-svn: 210499
|
|
|
|
|
|
|
| |
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
|
|
|
|
|
|
|
| |
never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210497
|
|
|
|
|
|
| |
We can just split targets_to_build in one place and make it immutable.
llvm-svn: 210496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately there's no way to elegantly do this with pre-canned
algorithms. Using a generating iterator doesn't work because you default
construct for each element, then move construct into the actual slot
(bad for copy but non-movable types, and a little unneeded overhead even
in the move-only case), so just write it out manually.
This solution isn't exception safe (if one of the element's ctors calls
we don't fall back, destroy the constructed elements, and throw on -
which std::uninitialized_fill does do) but SmallVector (and LLVM) isn't
exception safe anyway.
llvm-svn: 210495
|
|
|
|
| |
llvm-svn: 210494
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in PPCTargetLowering::PerformDAGCombine() that handles
unaligned Altivec vector loads generates a lvsl followed by a vperm.
As we've seen in numerous other places, the vperm instruction has a
big-endian bias, and this is fixed for little endian by complementing
the permute control vector and swapping the input operands. In this
case the lvsl is providing the permute control vector. Rather than
generating an lvsl and a complement operation, it is sufficient to
generate an lvsr instruction instead. Thus for LE code generation we
will generate an lvsr rather than an lvsl, and swap the other input
arguments on the vperm.
The existing test/CodeGen/PowerPC/vec_misalign.ll is updated to test
the code generation for PPC64 and PPC64LE, in addition to the existing
PPC32/G5 testing.
llvm-svn: 210493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't terminate location ranges for register-described variables
at the end of machine basic block if this register is never modified
in the function body, except for the prologue and epilogue. Prologue
location is guessed by FrameSetup flags on MachineInstructions, while
epilogue location is deduced from debug locations of instructions
in the basic blocks ending with return instructions.
This patch is mostly targeted to fix non-trivial debug locations for
variables addressed via stack and frame pointers.
It is not really a generic fix. We can still produce poor debug info
for register-described variables if this register *is* modified somewhere
in the function, but in unrelated places. This might be the case for the debug
info in optimized binaries (e.g. for local variables in inlined functions).
LiveDebugVariables pass in CodeGen attempts to fix this problem by adjusting
DBG_VALUE instructions, but this pass is tied to greedy register allocator,
which is used in optimized builds only. Proper fix would likely involve
generalizing LiveDebugVariables to all register allocators. See more discussion
in http://reviews.llvm.org/D3933 review thread.
I'm proceeding with this patch to fix immediate severe problems and
important cases, e.g. fix completely broken debug info with AddressSanitizer
and fix PR19307 (missing debug info for by-value std::string arguments).
llvm-svn: 210492
|
|
|
|
|
|
|
| |
'NSCopying' protocol when diagnosing block to ObjC pointer conversion.
// rdar://16739120
llvm-svn: 210491
|
|
|
|
|
|
| |
Thanks to Duncan P. N. Exon Smith and Owen Anderson for noticing.
llvm-svn: 210490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The armv7-windows-itanium environment is nearly identical to the MSVC ABI. It
has a few divergences, mostly revolving around the use of the Itanium ABI for
C++. VLA support is one of the extensions that are amongst the set of the
extensions.
This adds support for proper VLA emission for this environment. This is
somewhat similar to the handling for __chkstk emission on X86 and the large
stack frame emission for ARM. The invocation style for chkstk is still
controlled via the -mcmodel flag to clang.
Make an explicit note that this is an extension.
llvm-svn: 210489
|
|
|
|
|
|
| |
index comparisons.
llvm-svn: 210488
|
|
|
|
|
|
| |
Internal config.h headers are only meant to be included from the main file.
llvm-svn: 210487
|
|
|
|
|
|
|
|
|
|
|
| |
Originally this similar was initiated by Björn Steinbrink here:
http://reviews.llvm.org/D3437
Bug itself has been fixed by principal changes in MergeFunctions. Though
special checks for functions merging are still actual. And the test has
been accepted with slight modifications.
llvm-svn: 210486
|
|
|
|
|
|
|
|
|
|
|
| |
Tested and works fine with clang using libstdc++.
All indications are that this was fixed some time ago and isn't a problem with
any clang version we support.
I've added a note in PR6907 which is still open for some reason.
llvm-svn: 210485
|
|
|
|
|
|
| |
This expands the logic from r210141 to cover partial specializations too.
llvm-svn: 210484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support headers shouldn't use config.h definitions, and they should never be
undefined like this.
ConstantFolding.cpp was the only user of this facility and already includes
config.h for other math features, so it makes sense to move the checks there at
point of use.
(The implicit config.h was also quite dangerous -- removing the FEnv.h include
would have silently disabled math constant folding without causing any tests to
fail. Need to investigate -Wundef once the cleanup is done.)
This eliminates the last config.h include from LLVM headers, paving the way for
more consistent configuration checks.
llvm-svn: 210483
|
|
|
|
|
|
| |
Patch by Jacques-Pascal Deplaix
llvm-svn: 210482
|
|
|
|
| |
llvm-svn: 210481
|
|
|
|
|
|
| |
Patch by Jacques-Pascal Deplaix
llvm-svn: 210480
|
|
|
|
|
|
| |
from the x86 target machine. Should be no functional change.
llvm-svn: 210479
|
|
|
|
|
|
| |
It has other uses besides shift instructions.
llvm-svn: 210478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds new target specific combine rules to identify horizontal
add/sub idioms from BUILD_VECTOR dag nodes.
This patch also teaches the DAGCombiner how to canonicalize sequences of
insert_vector_elt dag nodes according to the following rule:
(insert_vector_elt (insert_vector_elt A, I0), I1) ->
(insert_vecto_elt (insert_vector_elt A, I1), I0)
This new canonicalization rule only triggers if the inner insert_vector
dag node has exactly one use; also, both indices must be known constants,
and I1 < I0.
This last rule made it possible to write a simpler algorithm to identify
horizontal add/sub patterns because now we don't have to worry about the
ordering of insert_vector_elt dag nodes.
llvm-svn: 210477
|
|
|
|
| |
llvm-svn: 210476
|
|
|
|
| |
llvm-svn: 210475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code in PPCTargetLowering::LowerMUL() for multiplying two
v16i8 values assumes that vector elements are numbered in big-endian
order. For little-endian targets, the vector element numbering is
reversed, but the vmuleub, vmuloub, and vperm instructions still
assume big-endian numbering. To account for this, we must adjust the
permute control vector and reverse the order of the input registers on
the vperm instruction.
The existing test/CodeGen/PowerPC/vec_mul.ll is updated to be executed
on powerpc64 and powerpc64le targets as well as the original powerpc
(32-bit) target.
llvm-svn: 210474
|