directy with ``make check-lit`` and are run as part of
``make check-all``.

In principle we should run lit's testsuite before testing LLVM using lit
so that any problems with lit get discovered before testing LLVM so we
can bail out early.  However this implementation (``check-all`` runs all
tests together) seemed simpler and will still report failing lit tests.

Note that the tests and the configured ``lit.site.cfg`` have to be
copied into the build directory to avoid polluting the source tree.

llvm-svn: 257221

llvm-svn: 257220

llvm-svn: 257219

llvm-svn: 257218

llvm-svn: 257217

llvm-svn: 257216

This creates one instance of TUL per HexagonShuffler, which avoids thread-safety
issues with future changes.

llvm-svn: 257215

We used to have code in SymbolTable constructor to add entry symbols, etc.
That code has been moved to Driver. We can remove the constructor.

llvm-svn: 257214

llvm-svn: 257213

llvm-svn: 257212

For historical reasons, some add* functions for SymbolTable returns a
pointer to a SymbolBody, while some are not. This patch is to make them
consistently return a pointer to a newly added symbol.

llvm-svn: 257211

with the one change that ThreadPlanStepOut::ThreadPlanStepOut
will now only advance the return address breakpoint to
the end of a source line, if we have source line debug information.
It will not advance to the end of a Symbol if we lack source line
information.  This, or the recognition of the LEAVE instruction
in r257209, would have fixed the regression that Siva was seeing.
Both were good changes, so I've made both.

Original commit message:

Performance improvement: Change lldb so that it puts a breakpoint
on the first branch instruction after a function return (or the end
of a source line), instead of a breakpoint on the return address,
to skip an extra stop & start of the inferior process.

I changed Process::AdvanceAddressToNextBranchInstruction to not
take an optional InstructionList argument - no callers are providing
a cached InstructionList today, and if this function was going to
do that, the right thing to do would be to fill out / use a
DisassemblerSP which is a disassembler with the InstructionList for
this address range.


http://reviews.llvm.org/D15708
<rdar://problem/23309838> 

llvm-svn: 257210

llvm-svn: 257209

There's a bug in versions of SWIG prior to 3.0.8 that prevent
these tests from succeeding with Python 3.x

llvm-svn: 257208

llvm-svn: 257207

Clang got itself into the situation where we mangled the same
constructor twice with two different constructor types.  After one of
the constructors were utilized, the tag used for one of the types
changed from class to struct because a class template became complete.
This resulted in one of the constructor types varying from the other
constructor.

Instead, force "base" constructor types to "complete" if the ABI doesn't
have constructor variants.  This will ensure that GlobalDecls for both
variants will get the same mangled name.

This fixes PR26029.

llvm-svn: 257205

Summary:
When we construct AppleObjCTrampolineHandler, if m_impl_fn_addr is
invalid, we call CanJIT(). If the gdb remote process does not support
allocating and deallocating memory, this call stack will include a call
to the AppleObjCRuntime constructor. The AppleObjCRuntime constructor
will then call the AppleObjCTrampolineHandler constructor, creating a
recursive call loop that eventually overflows the stack and segfaults.

Avoid this call loop by not constructing the AppleObjCTrampolineHandler
within AppleObjCRuntime until we actually need to use it.

Reviewers: clayborg, jingham

Subscribers: sas, lldb-commits

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 257204

R_X86_64_PLT32 is handled in the same way as R_X86_64_PC32 by
relocateOne(), so this function does not seems to be needed.
Without this code, all tests still pass.

http://reviews.llvm.org/D15971

llvm-svn: 257203

CFI tests do not require the CFI runtime library on Windows.
Do not add "cfi" as a dependency of "check-cfi" in that case.

llvm-svn: 257202

This is a bit more complex than that.

llvm-svn: 257201

The bug was introduced with changes for x86-64 fp128:
http://reviews.llvm.org/rL254653

I don't know why an x86 change is here, so I'll follow up in:
http://reviews.llvm.org/D15134

Should fix:
https://llvm.org/bugs/show_bug.cgi?id=26070

llvm-svn: 257200

Fix incorrect condition for enabling the CFI tests. This removes the following CMake warnings on Windows:

The dependency target "cfi" of target "check-all" does not exist.
The dependency target "cfi" of target "check-cfi-and-supported" does not exist.

llvm-svn: 257199

Look for PHI/Select in the same BB of the form

bb:
  %p = phi [false, %bb1], [true, %bb2], [false, %bb3], [true, %bb4], ...
  %s = select p, trueval, falseval

And expand the select into a branch structure. This later enables
jump-threading over bb in this pass.

Using the similar approach of SimplifyCFG::FoldCondBranchOnPHI(), unfold
select if the associated PHI has at least one constant.  If the unfolded
select is not jump-threaded, it will be folded again in the later
optimizations.

llvm-svn: 257198

Also sort includes.

llvm-svn: 257197

llvm-svn: 257196

llvm-svn: 257195

llvm-svn: 257194

llvm-svn: 257193

llvm-svn: 257192

It's strange that LoopInfo mostly owns the Loop objects, but that it
defers deleting them to the loop pass manager. Instead, change the
oddly named "updateUnloop" to "markAsRemoved" and have it queue the
Loop object for deletion. We can't delete the Loop immediately when we
remove it, since we need its pointer identity still, so we'll mark the
object as "invalid" so that clients can see what's going on.

llvm-svn: 257191

Summary:
Use llvm::any_of, llvm::find, etc.

No functional changes.

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 257190

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

llvm-svn: 257189

Summary:
r255334 matches bit-reverse pattern in InstCombine and generates calls to Instrinsic::bitreverse.

RBIT instruction is only available for ARMv6t2 and above. This patch has the intrinsic expanded during legalization for ARMv4 and ARMv5.

Patch by Z. Zheng <zhaoshiz@codeaurora.org>

Reviewers: apazos, jmolloy, weimingz

Subscribers: aemerson, rengolin, llvm-commits

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

llvm-svn: 257188

Summary: In ARMConstantIslandPass, which runs after Shrink Wrap pass, long jumps will be fixed up as BL (tBfar) which depends on spilling LR in epilogue.  However, shrink-wrap may remove the LR, which causes issues when the function returns.

Reviewers: qcolombet, rengolin

Subscribers: aemerson, rengolin

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

llvm-svn: 257187

llvm-svn: 257186

With the removal of the old landing pad code in r249918, CloningDirector is not
 used anywhere else. NFCI.

llvm-svn: 257185

Summary:
During legalization if i16, do not ASSERTZEXT the result of FP_TO_FP16.
Directly return an FP_TO_FP16 node with return type as the
promote-to-type of i16.

This patch also removes extraneous length check.  This legalization
should be valid even if integer and float types are of different
lengths.

This patch breaks a hard-float test for fp16 args.  The test is changed
to allow a vmov to zero-out the top bits, and also ensure that the
return value is in an FP register.

Reviewers: ab, jmolloy

Subscribers: srhines, llvm-commits

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

llvm-svn: 257184

llvm-svn: 257183

StackColoring rewrites the frame indicies of operations involving
allocas if it can find that the life time of two objects do not overlap.
MSVC EH needs to be kept aware of this if happens in the event that a
catch object has moved around.  However, we represent the non-existance
of a catch object with a sentinel frame index (INT_MAX).  This sentinel
also happens to be the EmptyKey of the SlotRemap DenseMap.  Testing for
whether or not we need to translate the frame index fails in this case
because we call the count method on the DenseMap with the EmptyKey,
leading to assertions.  Instead, check if it is our sentinel value
before trying to look into the DenseMap.

This fixes PR26073.

llvm-svn: 257182

Due to the new in-place ThinLTO symbol handling support added in
r257174, we now invoke renameModuleForThinLTO on the current
module from within the FunctionImport pass.

Additionally, renameModuleForThinLTO no longer needs to return the
Module as it is performing the renaming in place on the one provided.

This commit will be immediately preceeded by a companion clang patch to
remove its invocation of renameModuleForThinLTO.

llvm-svn: 257181