llvm-svn: 219587

llvm-svn: 219586

llvm-svn: 219585

This patch improves support for commutative instructions in the x86 memory folding implementation by attempting to fold a commuted version of the instruction if the original folding fails - if that folding fails as well the instruction is 're-commuted' back to its original order before returning.

This mainly helps the stack inliner better fold reloads of 3 (or more) operand instructions (VEX encoded SSE etc.) but by performing this in the lowest foldMemoryOperandImpl implementation it also replaces the X86InstrInfo::optimizeLoadInstr version and is now used by FastISel too.

Differential Revision: http://reviews.llvm.org/D5701

llvm-svn: 219584

A helper routine, MultiplyOverflows, was a less efficient
reimplementation of APInt's smul_ov and umul_ov.  While we are here,
clean up the code so it's more uniform.

No functionality change intended.

llvm-svn: 219583

While we ran getUnqualifiedType over the catch type,
it isn't enough for array types.  Use getUnqualifiedArrayType instead.

This fixes PR21252.

llvm-svn: 219582

llvm-svn: 219581

llvm-svn: 219580

llvm-svn: 219579

With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.

Several log lines have been added around PTY and stdout/stderr redirection
logic on the lldb client side.

Regarding remote llgs execution, see the following:

With these changes, remote llgs with $O now works properly:

$ lldb
(lldb) platform select remote-linux
(lldb) target create ~/some/inferior/exe
(lldb) gdb-remote {some-target}:{port}
(lldb) run

The sequence above will correctly redirect stdout/stderr over gdb-remote $O,
as is needed for remote debugging.  That sequence assumes there is a lldb-gdbserver
exe running on the target with {some-host}:{port}.

You can replace the gdb-remote command with a '(lldb) platform connect
connect://{target-ip}:{target-port}'.  If you do this and have a
lldb-platform running on the remote end, it will go ahead and launch
llgs for lldb for each target instance that is run/attached.

For local debugging with llgs, the following sequence also works, and
uses local PTYs instead to avoid $O and extra gdb-remote messages:

$ lldb
(lldb) settings set platform.plugin.linux.use-llgs true
(lldb) target create ~/some/inferior/exe
(lldb) run

The above will run the inferior using llgs on the local host, and
will use PTYs rather than $O redirection.

This change also removes the logging that happened after the fork but
before the exec when llgs is launching a new inferior process.  Some
aspect of the file handling during that portion of code would not do
the right thing with log handling.  We might want to go back later
and have that communicate over a pipe from the child to parent to pass
along any messages that previously were logged in that section of code.

llvm-svn: 219578

Indentation tidyup.

llvm-svn: 219577

llvm-svn: 219576

Those are expensive to create in cold cache scenarios. NFC.

llvm-svn: 219575

32 -> 16 bytes on x86_64. NFC.

llvm-svn: 219574

On x86_64 this brings it from 80 bytes to 64 bytes. Also make any member
variables private and clean up uses to go through the existing accessors.

NFC.

llvm-svn: 219573

Fix comment typo + spelling.

llvm-svn: 219572

llvm-svn: 219571

and !=) to support mixed complex and real operand types.

This requires removing an assert from SemaChecking, and adding support
both to the constant evaluator and the code generator to synthesize the
imaginary part when needed. This seemed somewhat cleaner than having
just the comparison operators force real-to-complex conversions.

I've added test cases for these operations. I'm really terrified that
there were *no* tests in-tree which exercised this.

This turned up when trying to build R after my change to the complex
type lowering.

llvm-svn: 219570

Patch by Charlie Turner.

llvm-svn: 219569

Consider the case where X is 2.  (2 <<s 31)/s-2147483648 is zero but we
would fold to X.  Note that this is valid when we are in the unsigned
domain because we require NUW: 2 <<u 31 results in poison.

This fixes PR21245.

llvm-svn: 219568

consider:
C1 = INT_MIN
C2 = -1

C1 * C2 overflows without a doubt but consider the following:
%x = i32 INT_MIN

This means that (%X /s C1) is 1 and (%X /s C1) /s C2 is -1.

N. B.  Move the unsigned version of this transform to InstSimplify, it
doesn't create any new instructions.

This fixes PR21243.

llvm-svn: 219567

consider:
mul i32 nsw %x, -2147483648

this instruction will not result in poison if %x is 1

however, if we transform this into:
shl i32 nsw %x, 31

then we will be generating poison because we just shifted into the sign
bit.

This fixes PR21242.

llvm-svn: 219566

for complex math.

This should fix the windows build bots that started having trouble here
and generally fix complex libcall emission on targets which use sret for
complex data types. It also makes the code a bit simpler (despite
calling into a much more complex bucket of code).

llvm-svn: 219565

Before:
  - (instancetype)initXxxxxxxxxxxxxxxxxxxxxxxxx:(id<x>)x
                                              y:(id<yyyyyyyyyyyyyyyyyyyy>)
                                                    y NS_DESIGNATED_INITIALIZER;
After:
  - (instancetype)initXxxxxxxxxxxxxxxxxxxxxxxxx:(id<x>)x
                                              y:(id<yyyyyyyyyyyyyyyyyyyy>)y
      NS_DESIGNATED_INITIALIZER;

llvm-svn: 219564

to pass in an opt build.

The test case in question does show UBSan catching the error, but it
doesn't then successfully set the exit code of the program. I'll let the
UBSan folks sort out why. It should reproduce trivially with an
optimized build.

llvm-svn: 219563

getSmallConstantTripCount even when it isn't the exiting block.

I missed this in my first audit, very sorry. This was found in LNT and
elsewhere. I don't have a test case, but it was completely obvious from
inspection that this was the problem. I'll see if I can reduce a test
case, but I'm not really hopeful, and the value seems quite low.

llvm-svn: 219562

llvm-svn: 219561

Reviewed at http://reviews.llvm.org/D5738

This adds an SB API into SBProcess:
  bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active.

llvm-svn: 219560

llvm-svn: 219559

that guard its usage. Without this, we can get unused function warnings
when backtraces are disabled.

llvm-svn: 219558

operators where one type is a C complex type, and to emit both the
efficient and correct implementation for complex arithmetic according to
C11 Annex G using this extra information.

For both multiply and divide the old code was writing a long-hand
reduced version of the math without any of the special handling of inf
and NaN recommended by the standard here. Instead of putting more
complexity here, this change does what GCC does which is to emit
a libcall for the fully general case.

However, the old code also failed to do the proper minimization of the
set of operations when there was a mixed complex and real operation. In
those cases, C provides a spec for much more minimal operations that are
valid. Clang now emits the exact suggested operations. This change isn't
*just* about performance though, without minimizing these operations, we
again lose the correct handling of infinities and NaNs. It is critical
that this happen in the frontend based on assymetric type operands to
complex math operations.

The performance implications of this change aren't trivial either. I've
run a set of benchmarks in Eigen, an open source mathematics library
that makes heavy use of complex. While a few have slowed down due to the
libcall being introduce, most sped up and some by a huge amount: up to
100% and 140%.

In order to make all of this work, also match the algorithm in the
constant evaluator to the one in the runtime library. Currently it is
a broken port of the simplifications from C's Annex G to the long-hand
formulation of the algorithm.

Splitting this patch up is very hard because none of this works without
the AST change to preserve non-complex operands. Sorry for the enormous
change.

Follow-up changes will include support for sinking the libcalls onto
cold paths in common cases and fastmath improvements to allow more
aggressive backend folding.

Differential Revision: http://reviews.llvm.org/D5698

llvm-svn: 219557

Summary: Implement the most basic form of conditional branches in Mips fast-isel.

Test Plan:
br1.ll
run 4 flavors of test-suite. mips32 r1/r2 and at -O0/O2

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits, rfuhler

Differential Revision: http://reviews.llvm.org/D5583

llvm-svn: 219556

Reviewed at http://reviews.llvm.org/D5736

The new test cases for ASan fail if the llvm build that is used with LLDB doesn't have compiler-rt (because the resulting compiler then cannot build with -fsanitize=address). Let's include compiler-rt in build-llvm.pl script and make sure we actually *build* it by removing the NO_RUNTIME_LIBS=1 argument used in the make line. After this, the ASan tests pass on a fresh svn checkout.

llvm-svn: 219555

AddressSanitizer by adding dependencies and definitions.

llvm-svn: 219554

do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class.  Also expose that to the SB API's.

Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.

I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.

llvm-svn: 219553

declaration in the instantiation if the previous declaration came from another
definition of the class template that got merged into the pattern definition.

llvm-svn: 219552

Summary: This fixes PR21235.

Test Plan: Includes an automated test.

Reviewers: hansw

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D5718

llvm-svn: 219551

routines and fix all of the bugs they expose.

I hit a test case that crashed even without these asserts due to passing
a non-exiting latch to the ExitingBlock parameter of the trip count
computation machinery. However, when I add the nice asserts, it turns
out we have plenty of coverage of these bugs, they just didn't manifest
in crashers.

The core problem seems to stem from an assumption that the latch *is*
the exiting block. While this is often true, and somewhat the "normal"
way to think about loops, it isn't necessarily true. The correct way to
call the trip count routines in a *generic* fashion (that is, without
a particular exit in mind) is to just use the loop's single exiting
block if it has one. The trip count can't be computed generically unless
it does. This works great for the loop vectorizer. The loop unroller
actually *wants* to select the latch when it has to chose between
multiple exits because for unrolling it is the latch trips that matter.
But if this is the desire, it needs to explicitly guard for non-exiting
latches and check for the generic trip count in that case.

I've added the asserts, and added convenience APIs for querying the trip
count generically that check for a single exit block. I've kept the APIs
consistent between computing trip count and trip multiples.

Thansk to Mark for the help debugging and tracking down the *right* fix
here!

llvm-svn: 219550

but in the conditional rather than at initialization time.

llvm-svn: 219549

llvm-svn: 219548