| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
a single early exit.
And factor the subsequent cast<> from all but one block into a single
variable.
No functionality changed.
llvm-svn: 216645
|
| |
|
|
|
|
|
|
|
|
| |
functionality changed.
Separating this into two functions wasn't helping. There was a decent
amount of boilerplate duplicated, and some subsequent refactorings here
will pull even more common code out.
llvm-svn: 216644
|
| |
|
|
|
|
|
|
|
| |
file.
Changing code that is covered by these tests is just too hard to debug
currently, and now it will be clear the nature of the changes.
llvm-svn: 216643
|
| |
|
|
|
|
|
|
| |
Several combines involving icmp (shl C2, %X) C1 can be simplified
without introducing any new instructions. Move them to InstSimplify;
while we are at it, make them more powerful.
llvm-svn: 216642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
don't mark the field as initialized until the next initializer instead of
instantly. Since this checker is AST based, statements are processed in tree
order instead of following code flow. This can result in different warnings
from just reordering the code. Also changed to use one checker per constructor
instead of creating a new checker per field.
class T {
int x, y;
// Already warns
T(bool b) : x(!b ? (1 + y) : (y = 5)) {}
// New warning added here, previously (1 + y) comes after (y = 5) in the AST
// preventing the warning.
T(bool b) : x(b ? (y = 5) : (1 + y)) {}
};
llvm-svn: 216641
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The included test case would fail, because the MI PHI node would have two
operands from the same predecessor.
This problem occurs when a switch instruction couldn't be selected. This happens
always, because there is no default switch support for FastISel to begin with.
The problem was that FastISel would first add the operand to the PHI nodes and
then fall-back to SelectionDAG, which would then in turn add the same operands
to the PHI nodes again.
This fix removes these duplicate PHI node operands by reseting the
PHINodesToUpdate to its original state before FastISel tried to select the
instruction.
This fixes <rdar://problem/18155224>.
llvm-svn: 216640
|
| |
|
|
|
|
| |
contexts, so that we can merge them when we merge the surrounding context.
llvm-svn: 216639
|
| |
|
|
| |
llvm-svn: 216638
|
| |
|
|
|
|
|
|
| |
breakpoint if no breakpoint id is specified.
<rdar://problem/17885160>
llvm-svn: 216637
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Image Base field in the PE/COFF header is used as hint for the loader.
If the loader can load the executable at the specified address, that's
fine, but if not, it has to load it at a different address.
If that happens, the loader has to fix up the addresses in the
executable by adding the offset. The list of addresses that need to
be fixed is in .reloc section.
This patch is to emit x64 .reloc section contents.
llvm-svn: 216636
|
| |
|
|
| |
llvm-svn: 216635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently instructions are folded very aggressively for AArch64 into the memory
operation, which can lead to the use of killed operands:
%vreg1<def> = ADDXri %vreg0<kill>, 2
%vreg2<def> = LDRBBui %vreg0, 2
... = ... %vreg1 ...
This usually happens when the result is also used by another non-memory
instruction in the same basic block, or any instruction in another basic block.
This fix teaches hasTrivialKill to not only check the LLVM IR that the value has
a single use, but also to check if the register that represents that value has
already been used. This can happen when the instruction with the use was folded
into another instruction (in this particular case a load instruction).
This fixes rdar://problem/18142857.
llvm-svn: 216634
|
| |
|
|
|
|
|
|
| |
on CXXRecordDecls when merging definitions, and make it pass by not trying to
save and restore this flag across AST serialization/deserialization. For
CXXRecordDecls, we have a separate mechanism to manage this.
llvm-svn: 216633
|
| |
|
|
|
|
|
|
| |
the memory operation."
Quentin pointed out that this is not the correct approach and there is a better and easier solution.
llvm-svn: 216632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Introduce support::ulittleX_t::ref type to Support/Endian.h and use it in x86 JIT
to enforce correct endianness and fix unaligned accesses.
Test Plan: regression test suite
Reviewers: lhames
Subscribers: ributzka, llvm-commits
Differential Revision: http://reviews.llvm.org/D5011
llvm-svn: 216631
|
| |
|
|
| |
llvm-svn: 216630
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operation.
Currently instructions are folded very aggressively into the memory operation,
which can lead to the use of killed operands:
%vreg1<def> = ADDXri %vreg0<kill>, 2
%vreg2<def> = LDRBBui %vreg0, 2
... = ... %vreg1 ...
This usually happens when the result is also used by another non-memory
instruction in the same basic block, or any instruction in another basic block.
If the computed address is used by only memory operations in the same basic
block, then it is safe to fold them. This is because all memory operations will
fold the address computation and the original computation will never be emitted.
This fixes rdar://problem/18142857.
llvm-svn: 216629
|
| |
|
|
|
|
| |
scope when checking for conflicts.
llvm-svn: 216628
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix r216438 to catch more complicated self-initialized in std::move. For
instance, "Foo f = std::move(cond ? OtherFoo : (UNUSED_VALUE, f));"
Make sure that BinaryConditionalOperator, ConditionalOperator, BinaryOperator
with comma operator, and OpaqueValueExpr perform the correct usage forwarding
across the three uninitialized value checkers.
llvm-svn: 216627
|
| |
|
|
|
|
|
|
|
|
|
|
| |
such. This was causing:
(lldb) disassemble -n '-<TAB>
to crash.
<rdar://problem/18134531>
llvm-svn: 216626
|
| |
|
|
|
|
| |
and so can only be used in the script interpreter.
llvm-svn: 216625
|
| |
|
|
|
|
|
| |
Adding a check on buffer lenght to avoid a __warn_memset_zero_len
warning on GCC 4.8.2.
llvm-svn: 216624
|
| |
|
|
| |
llvm-svn: 216623
|
| |
|
|
| |
llvm-svn: 216622
|
| |
|
|
|
|
|
|
|
| |
When the address comes directly from a shift instruction then the address
computation cannot be folded into the memory instruction, because the zero
register is not available as a base register. Simplify addess needs to emit the
shift instruction and use the result as base register.
llvm-svn: 216621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Query CompilationDatabase right before running each compilation. This allows
supporting compilation databases that change external state required for
successful compilation.
Reviewers: klimek, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5086
llvm-svn: 216620
|
| |
|
|
|
|
|
|
|
|
|
|
| |
hasn't been used yet (PR20746)
This shouldn't really be allowed, but it comes up in real code (see PR). As
long as the decl hasn't been used there's no technical difficulty in supporting
it, so downgrade the error to a warning.
Differential Revision: http://reviews.llvm.org/D5087
llvm-svn: 216619
|
| |
|
|
|
|
| |
Unfortunately this is only used by ld64, so no testcase, but should fix the darwin LTO bootstrap.
llvm-svn: 216618
|
| |
|
|
|
|
|
|
|
| |
Use the zero register directly when possible to avoid an unnecessary register
copy and a wasted register at -O0. This also uses integer stores to store a
positive floating-point zero. This saves us from materializing the positive zero
in a register and then storing it.
llvm-svn: 216617
|
| |
|
|
| |
llvm-svn: 216616
|
| |
|
|
| |
llvm-svn: 216615
|
| |
|
|
|
|
|
|
|
|
| |
ownership is explicitly done using unique_ptr.
Only those callers who are dynamically passing ownership should need the
3 argument form. Those accepting the default ("do pass ownership")
should do so explicitly with a unique_ptr now.
llvm-svn: 216614
|
| |
|
|
|
|
|
|
| |
FastEmitInst_ri was constraining the first operand without checking if it is
a virtual register. Use constrainOperandRegClass as all the other
FastEmitInst_* functions.
llvm-svn: 216613
|
| |
|
|
| |
llvm-svn: 216612
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 216611
|
| |
|
|
|
|
|
|
|
|
| |
into primary class's named categories before looking
into their protocols. This is because categories are
part of the public interface and , just as primary class,
preference should be given to them before class
(and category) protocols. // rdar://18013929
llvm-svn: 216610
|
| |
|
|
| |
llvm-svn: 216609
|
| |
|
|
| |
llvm-svn: 216608
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a lightweight wrapper around a pid. It is intended to be
lightweight enough to serve as a replacement anywhere we currently
store a pid. It provides convenience methods and common process
operations.
This patch does not yet make use of HostProcess anywhere.
llvm-svn: 216607
|
| |
|
|
|
|
|
|
|
| |
LLDB had implemented its own DynamicLibrary class for plugin
support. LLVM has an equivalent mechanism, so this patch deletes
the duplicated code in LLDB and updates LLDB to reference the
mechanism provided by LLVM.
llvm-svn: 216606
|
| |
|
|
|
|
|
|
| |
MemoryBuffer::getMemBuffer to move initialization now that it returns by unique_ptr instead of raw pointer.
Cleanup/improvements following r216583.
llvm-svn: 216605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instructions like 'fxsave' and control flow instructions like 'jne'
match any operand size. The loop I added to the Intel syntax matcher
assumed that using a different size would give a different instruction.
Now it handles the case where we get the same instruction for different
memory operand sizes.
This also allows us to remove the hack we had for unsized absolute
memory operands, because we can successfully match things like 'jnz'
without reporting ambiguity. Removing this hack uncovered test case
involving 'fadd' that was ambiguous. The memory operand could have been
single or double precision.
llvm-svn: 216604
|
| |
|
|
| |
llvm-svn: 216603
|
| |
|
|
|
|
|
|
| |
We try to perform this transform in InstSimplify but we aren't always
able to. Sometimes, we need to insert a bitcast if X and Y don't have
the same time.
llvm-svn: 216598
|
| |
|
|
|
|
|
|
|
| |
It's incorrect to perform this simplification if the types differ.
A bitcast would need to be inserted for this to work.
This fixes PR20771.
llvm-svn: 216597
|
| |
|
|
| |
llvm-svn: 216586
|
| |
|
|
| |
llvm-svn: 216585
|
| |
|
|
| |
llvm-svn: 216584
|
| |
|
|
| |
llvm-svn: 216583
|
| |
|
|
|
|
| |
It caused PR 20771. I'll land a test on the clang side.
llvm-svn: 216582
|