llvm-svn: 181873

llvm-svn: 181872

We only ever implemented one and that one is not actually all that
helpful (e.g. gets incorrectly triggered by macros).

llvm-svn: 181871

The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.

Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After:  #define DEREF_AND_CALL_F(parameter) f(*parameter)
llvm-svn: 181870

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.

One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).

llvm-svn: 181869

BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.

This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.

llvm-svn: 181868

It's an LP64 platform.

llvm-svn: 181867

Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!

llvm-svn: 181866

These intrinsics use the __builtin_shuffle() function to extract the
low and high half, respectively, of a 128-bit NEON vector. Currently,
they're defined to use bitcasts to simplify the emitter, so we get code
like:
uint16x4_t vget_low_u32(uint16x8_t __a) {
  return (uint32x2_t) __builtin_shufflevector((int64x2_t) __a,
                                              (int64x2_t) __a,
                                              0);
}

While this works, it results in those bitcasts going all the way through
to the IR, resulting in code like:
  %1 = bitcast <8 x i16> %in to <2 x i64>
  %2 = shufflevector <2 x i64> %1, <2 x i64> undef, <1 x i32>
  %zeroinitializer
  %3 = bitcast <1 x i64> %2 to <4 x i16>

We can instead easily perform the operation directly on the input vector
like:

uint16x4_t vget_low_u16(uint16x8_t __a) {
  return __builtin_shufflevector(__a, __a, 0, 1, 2, 3);
}

Not only is that much easier to read on its own, it also results in
cleaner IR like:

  %1 = shufflevector <8 x i16> %in, <8 x i16> undef,
                     <4 x i32> <i32 0, i32 1, i32 2, i32 3>

This is both easier to read and easier for the back end to reason
about effectively since the operation is obfuscating the source with
bitcasts.

rdar://13894163

llvm-svn: 181865

ELFRelocationEntry::operator<(): Try to stabilize the order. r_offset was insufficient to sort Relocs.

It should fix llvm/test/CodeGen/ARM/ehabi-mc-compact-pr*.ll on some hosts.

  RELOCATION RECORDS FOR [.ARM.exidx]:
  0 R_ARM_PREL31 .text
  0 R_ARM_NONE __aeabi_unwind_cpp_pr0

FIXME: I am not sure of the directions of extra comparators, in Type and Index.
For now, they are different from the direction in r_offset.

llvm-svn: 181864

process StopLocker (if there is a process) before it will hand out SBValues.  We were doing this in 
an ad hoc fashion previously, and then playing whack-a-mole whenever we found a place where we should
have been doing this but weren't.  Really, it doesn't make sense to be poking at SBValues when the target
is running, the dynamic and synthetic values can't really be computed, and the underlying memory may be
incoherent.

<rdar://problem/13819378> Sometimes when stepping fast, my inferior is killed by debugserver

llvm-svn: 181863

No functionality change.

llvm-svn: 181862

Patch by David Fang!

llvm-svn: 181861

InstCombine can be uncooperative to vectorization and sink loads into
conditional blocks. This prevents vectorization.

Undo this optimization if there are unconditional memory accesses to the same
addresses in the loop.

radar://13815763

llvm-svn: 181860

Don’t pop the process input reader for a “stop” event if ShouldBroadcastEvent has restarted the process.

llvm-svn: 181859

llvm-svn: 181858

llvm-svn: 181857

The command "po" by itself yields odd errors. I fixed the alias.

llvm-svn: 181856

Changes to the libc++ std::string data formatter

llvm-svn: 181855

the run line.

llvm-svn: 181854

llvm-svn: 181853

llvm-svn: 181852

This is expanding Ben's original heuristic for short basic blocks to
also work for longer basic blocks and huge use lists.

Scan the basic block and the use list in parallel, terminating the
search when the shorter list ends. In almost all cases, either the basic
block or the use list is short, and the function returns quickly.

In one crazy test case with very long use chains, CodeGenPrepare runs
400x faster. When compiling ARMDisassembler.cpp it is 5x faster.

<rdar://problem/13840497>

llvm-svn: 181851

A first pass at auto completion for variables and their children. This is currently hooked up for "frame variable" only. With a little work we can also enable it for the "expression" command and also for other things.

llvm-svn: 181850

llvm-svn: 181849

llvm-svn: 181848

found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331

llvm-svn: 181847

This simplifies error recovery elsewhere, eliminating the crash in
<rdar://problem/13853540>.

llvm-svn: 181846

llvm-svn: 181845

llvm-svn: 181844

There were two problems that made llvm-objdump -r crash:
- for non-scattered relocations, the symbol/section index is actually in the
  (aptly named) symbolnum field.
- sections are 1-indexed.

llvm-svn: 181843

The transformation happening here is that we want to turn a
"mul(ext(X), ext(X))" into a "vmull(X, X)", stripping off the extension. We have
to make sure that X still has a valid vector type - possibly recreate an
extension to a smaller type. In case of a extload of a memory type smaller than
64 bit we used create a ext(load()). The problem with doing this - instead of
recreating an extload - is that an illegal type is exposed.

This patch fixes this by creating extloads instead of ext(load()) sequences.

Fixes PR15970.

radar://13871383

llvm-svn: 181842

Combine N_GSYM stab entries with their non-stab counterpart (data symbols) to make the symbol table smaller with less duplicate named symbols.

llvm-svn: 181841

Fixed the test case to pass on Darwin. This might pass on linux as well. The test case now properly validates g_points as a global for the class A version, and the static variable for the file static.

llvm-svn: 181840

This prevents an overflow and assertion when the number of bits cannot be
stored in 64-bits.

llvm-svn: 181839

CXAAtExitFn was set outside a loop and before optimizations where functions
can be deleted. This patch will set CXAAtExitFn inside the loop and after
optimizations.

Seg fault when running LTO because of accesses to a deleted function.
rdar://problem/13838828

llvm-svn: 181838

llvm-svn: 181837

This built clean with clang, but if we see false positives on the bots
then we'll revert and turn it into a compiler specific check.

llvm-svn: 181836

happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.

llvm-svn: 181835

llvm-svn: 181834