[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear

Bug Pattern:
    # BB#0:                                 # %entry
    cmpldi  3, 0
    beq-  0, .LBB0_2
    # BB#1:                                 # %exit
    lwz 4, 0(3)
    #TC_RETURNd8 LVComputationKind 0
    .LBB0_2:                                # %cond.false
    mflr 0
    std 0, 16(1)
    stdu 1, -96(1)
    .Ltmp0:
    .cfi_def_cfa_offset 96
    .Ltmp1:
    .cfi_offset lr, 16
    bl __assert_fail
    nop

The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.

Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton

http://reviews.llvm.org/D17606

llvm-svn: 265112

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

This is a recommit of r265095 after fixing the Windows issues.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111

Fix MSVC warning "comparison of integers of different signs" (NFC)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265110

Fix S390 big endian detection

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265109

Const correctness in raw_sha1_ostream (NFC)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265108

Add support for computing SHA1 in LLVM

Provide a class to generate a SHA1 from a sequence of bytes, and
a convenience raw_ostream adaptor.
This will be used to provide a "build-id" by hashing the Module
block when writing bitcode. ThinLTO will use this information for
incremental build.

Reapply r265094 which was reverted in r265102 because it broke
MSVC bots (constexpr is not supported).

http://reviews.llvm.org/D16325

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265107

Improve CHECK-NOT robustness of dllexport tests

This changes some dllexport tests, to verify that some symbols that
should not be exported are not, in a way that improves the robustness
of CHECK-SAME interaction with CHECK-NOT.

We plan to enable dllimport/dllexport support for the PS4, and these
changes are for points we noticed in our internal testing.

Patch by Warren Ristow!

llvm-svn: 265106

Use range-based for loops. NFC.

llvm-svn: 265105

Visual Studio native visualizers for clang::TemplateSpecializationType

Displays a template specialization as, say, A<int, double>. Does not
yet handle UncommonTemplateNameStorage, QualifiedTemplateName, or
DependentTemplateName, but still more than worthwhile

llvm-svn: 265104

[analyzer] Prefer accessor method in extension over category in CallEvent.

In ObjCMethodCall:getRuntimeDefinition(), if the method is an accessor in a
category, and it doesn't have a self declaration, first try to find the method
in a class extension. This works around a bug in Sema where multiple accessors
are synthesized for properties in class extensions that are redeclared in a
category. The implicit parameters are not filled in for the method on the
category, which causes a crash when trying to synthesize a getter for the
property in BodyFarm. The Sema bug is tracked as rdar://problem/25481164.

rdar://problem/25056531

llvm-svn: 265103

Revert "Add support for computing SHA1 in LLVM"

This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265102

Don't insert stackrestore on deoptimizing returns

They're not necessary (since the stack pointer is trivially restored on
return), and the way LLVM inserts the stackrestore calls breaks the
IR (we get a stackrestore between the deoptimize call and the return).

llvm-svn: 265101

Don't insert lifetime end markers on deoptimizing returns

They're not necessary (since the lifetime of the alloca is trivially
over due to the return), and the way LLVM inserts the lifetime.end
markers breaks the IR (we get a lifetime end marker between the
deoptimize call and the return).

llvm-svn: 265100

Don't use an i64 return type with webkit_jscc

Re-enable an assertion enabled by Justin Lebar in rL265092.  rL265092
was breaking test/CodeGen/X86/deopt-intrinsic.ll because webkit_jscc
does not like non-i64 return types.  Change the test case to not do
that.

llvm-svn: 265099

AArch64ISelLowering: Remove unused variables/arguments; NFC

llvm-svn: 265098

Fix Sub-register Rewriting in Aggressive Anti-Dependence Breaker

Previously, HandleLastUse would delete RegRef information for sub-registers
if they were dead even if their corresponding super-register were still live.

If the super-register were later renamed, then the definitions of the
sub-register would not be updated appropriately. This patch alters the
behavior so that RegInfo information for sub-registers is only deleted when
the sub-register and super-register are both dead.

This resolves PR26775. This is the mirror image of Hal's r227311 commit.

Author: Tom Jablin (tjablin)
Reviewers: kbarton uweigand nemanjai hfinkel

http://reviews.llvm.org/D18448

llvm-svn: 265097

Add missing test for the "Module hash in bitcode" added in r265095

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265096

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265095

Add support for computing SHA1 in LLVM

Provide a class to generate a SHA1 from a sequence of bytes, and
a convenience raw_ostream adaptor.
This will be used to provide a "build-id" by hashing the Module
block when writing bitcode. ThinLTO will use this information for
incremental build.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265094

Revert "Protect some assertions with NDEBUG rather than DEBUG()."

This reverts r265092, because it breaks CodeGen/X86/deopt-intrinsic.ll.

llvm-svn: 265093

Protect some assertions with NDEBUG rather than DEBUG().

DEBUG() only runs if you pass -debug, but these assertions are generally
useful.

llvm-svn: 265092

[NVPTX] Add a truncate DAG node to some calls.

Summary:
Previously, we were running afoul of the assertion

  EVT(CLI.Ins[i].VT) == InVals[i].getValueType() && "LowerCall emitted a value with the wrong type!"

in SelectionDAGBuilder.cpp when running the NVPTX/i8-param.ll test.
This is because our backend (for some reason) treats small return values
as i32, but it wasn't ever truncating the i32 back down to the expected
width in the DAG.

Unclear to me whether this fixes any actual bugs -- in this test, at
least, the generated code is unchanged.

Reviewers: jingyue

Subscribers: llvm-commits, tra, jholewinski

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

llvm-svn: 265091

[NVPTX] Read __CUDA_FTZ from module flags in NVVMReflect.

Summary:
Previously the NVVMReflect pass would read its configuration from
command-line flags or a static configuration given to the pass at
instantiation time.

This doesn't quite work for clang's use-case.  It needs to pass a value
for __CUDA_FTZ down on a per-module basis.  We use a module flag for
this, so the NVVMReflect pass needs to be updated to read said flag.

Reviewers: tra, rnk

Subscribers: cfe-commits, jholewinski

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

llvm-svn: 265090

[NVPTX] Annotate some instructions as hasSideEffects = 0.

Summary:
Tablegen tries to infer this from the selection DAG patterns defined for
the instructions, but it can't always.

An instructive example is CLZr64.  CLZr32 is correctly inferred to have
no side-effects, but the selection DAG pattern for CLZr64 is slightly
more complicated, and in particular the ctlz DAG node is not at the root
of the pattern.  Thus tablegen can't infer that CLZr64 has no
side-effects.

Reviewers: jholewinski

Subscribers: jholewinski, tra, llvm-commits

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

llvm-svn: 265089

[ifcnv] Add brief comment explaining what ifcnv is.

llvm-svn: 265088

Fix Windows build (typo in disk_space() implementation)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265087

Fixed an issue that could cause debugserver to return two stop reply packets ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling:

rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
    if (!DNBProcessInterrupt(m_ctx.ProcessID()))
        HandlePacket_last_signal (NULL);
    return rnb_success;
}

In the call to DNBProcessInterrupt we did:

nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
    MachProcessSP procSP;
    if (GetProcessSP (pid, procSP))
        return procSP->Interrupt();
    return false;
}

This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.

To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets.
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.

The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)

Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...

As time goes on we should add more packet validators.

<rdar://problem/22859505>

llvm-svn: 265086

[LTO] Inherit options from Codegen before initializing TargetMachine.

This fixes bootstrap of llvm-tblgen (with LTO) and PR27150.
Slightly longer explanation follows.

Emission of .init_array instead of .ctors is supported only on a
subset of the Target LLVM supports. Codegen needs to be conservative
and always emit .ctors unless instructed otherwise (based on target).
If the dynamic linker sees .init_array it completely ignores
what's inside .ctors and therefore some constructors are not called
(and this causes llvm-tblgen to crash on startup).

Teach LLD/LTO about the Codegen options so we end up always emitting
.init_array and avoid this issue.
In future, we might end up supporting mix of .ctors and .init_array
in different input files if this shows up as a real-world use case.
The way gold handles this case is mapping .ctors from input into
.init_array in output. There's also another caveat because
as far as I understand .ctors run in reverse order so when we do
the copy/mapping we need to reverse copy in the output if there's
more than one ctor. That's why I'd rather avoid this complicate logic
unless there's a real need.

An analogous reasoning holds for .dtors/.fini_array.

llvm-svn: 265085

[LoopVectorize] Don't unconditionally print vectorization diagnostics
when compiling with LTO.

r244523 a new class DiagnosticInfoOptimizationRemarkAnalysisAliasing for
optimization analysis remarks related to pointer aliasing without
guarding it in isDiagnosticEnabled in LLVMContext.cpp. This caused the
diagnostic message to be printed unconditionally when compiling with
LTO.

This commit cleans up isDiagnosticEnabled and makes sure all the
vectorization optimization remarks are guarded.

rdar://problem/25382153

llvm-svn: 265084

[CUDA] Fix typo in __clang_cuda_runtime_wrapper.h.

We're #including the wrong file!

llvm-svn: 265083

Add disk_space() to llvm::fs

Summary: Adapted from Boost::filesystem.
(This is a reapply by reverting commit r265080 and fixing the WinAPI part)

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265082

testcase gardening: update the emissionKind enum to the new syntax. (NFC)

llvm-svn: 265081

Revert "Add disk_space() to llvm::fs"

This reverts commit r265074 and r265068.
Breaks windows build

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265080

Fix a captialization error in r265077.

llvm-svn: 265079

Adapt to LLVM API change in r265077.
EmissionKind moved from DIBuilder to DICompileUnit.

<rdar://problem/25427165>

llvm-svn: 265078

Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.

This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder
into DICompileUnit. DIBuilder is not the right place for this enum to live
in — a metadata consumer should not have to include DIBuilder.h.
I also added a Verifier check that checks that the emission kind of a
DICompileUnit is actually legal.

http://reviews.llvm.org/D18612
<rdar://problem/25427165>

llvm-svn: 265077

Follow-up to r265036: I got these iterators mixed up

llvm-svn: 265076

clang-format the large enum definitions in LLVMBitCodes.h

Suggestion from Duncan in a review thread.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265075

Use const ref instead of value for Twine in the disk_space() API

Thanks Rui for noticing!

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265074

ELF: Correctly handle --whole-archive for thin archives.

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

llvm-svn: 265073

Update release notes with list of checks added since 3.8.

Fix some checks documentation style.

Differential revision: http://reviews.llvm.org/D18582

llvm-svn: 265072

lit: python3 compatibility fix

llvm-svn: 265070

Create thin archive in GNU format to fix test on OS X.

llvm-svn: 265069

Add disk_space() to llvm::fs

Summary: Adapted from Boost::filesystem.
(This is a reapply by reverting commit r265062 and fixing the WinAPI part)

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265068

Move asm-printer-topological-order.ll to PowerPC backend

llvm-svn: 265067

Object: Add function for moving thin archive object buffer vector out of Archive.

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

llvm-svn: 265066

Object: Correctly read thin archives containing absolute paths.

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

llvm-svn: 265065

[AsmPrinter] Print aliases in topological order

Print aliases in topological order, that is, for any alias a = b,
b must be printed before a. This is because on some targets (e.g. PowerPC)
linker expects aliases in such an order to generate correct TOC information.

GCC also prints aliases in topological order.

llvm-svn: 265064

Fix PR26940 where compiles times regressed massively.

Patch by Jonas Paulsson. Original description:
Bugfix in buildSchedGraph() to make -dag-maps-huge-region work properly

I found that the reduction of the maps did in fact never happen in this
test case. This was because *all* the stores / loads were made with
addresses from arguments and they thus became "unknown" stores / loads.
Fixed by removing continue statements and making sure that the test for
reduction always takes place.

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

llvm-svn: 265063

Revert "Add disk_space() to llvm::fs"

Breaks windows bot.
This reverts commit r265050.
This reverts commit r265055.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265062

Preserve blockaddress use edges in the module splitter.

"blockaddress" can not apply to an external function. All
blockaddress constant uses must belong to the same module as the
definition of the target function.

llvm-svn: 265061

[NVPTX] Infer __nvvm_reflect as nounwind, readnone

This patch simply mirrors the attributes we give to @llvm.nvvm.reflect
to the __nvvm_reflect libdevice call.  This shaves about 30% of the code
in libdevice away because of CSE opportunities.  It's also helps us
figure out that libdevice implementations of transcendental functions
don't have side-effects.

llvm-svn: 265060

[ELF] Implement infrastructure for thunk code creation

Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf

- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.

- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.

- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.

- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.

- The patch supports the only type of thunk code for each target. For now,
it is enough.

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

llvm-svn: 265059

ELF: Add more variants of ignored flags.

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

llvm-svn: 265058

[CMake] Provide the ability to skip stripping when generating dSYMs

For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting COMPILER_RT_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.

llvm-svn: 265057

Define a utility function to read -O and lto-O options.

llvm-svn: 265056

Wdocumentation parameter fix

llvm-svn: 265055

fix typo; NFC

llvm-svn: 265054

ELF: Add flag for controlling LTO optimization level.

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

llvm-svn: 265053

Fixed signed/unsigned warning

llvm-svn: 265052

[AArch64] Allow loads with imp-def to be handled in getMemOpBaseRegImmOfsWidth()

Summary:
This change will allow loads with imp-def to be clustered in machine-scheduler pass.
areMemAccessesTriviallyDisjoint() can also handle loads with imp-def.

Reviewers: mcrosier, jmolloy, t.p.northover

Subscribers: aemerson, rengolin, mcrosier, llvm-commits

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

llvm-svn: 265051

Add disk_space() to llvm::fs

Summary: Adapted from Boost::filesystem.

Reviewers: bruno, silvas

Subscribers: tberghammer, danalbert, llvm-commits, srhines

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265050

[PowerPC] Cleanup test/CodeGen/PowerPC/qpx-load-splat.ll

Removing unnecessary attributes and metadata...

llvm-svn: 265049

[x86] add memset tests to show another potential improvement

llvm-svn: 265048

[PowerPC] Add a late MI-level pass for QPX load/splat simplification

Chapter 3 of the QPX manual states that, "Scalar floating-point load
instructions, defined in the Power ISA, cause a replication of the source data
across all elements of the target register." Thus, if we have a load followed
by a QPX splat (from the first lane), the splat is redundant. This adds a late
MI-level pass to remove the redundant splats in some of these cases
(specifically when both occur in the same basic block).

This optimization is scheduled just prior to post-RA scheduling. It can't happen
before anything that might replace the load with some already-computed quantity
(i.e. store-to-load forwarding).

llvm-svn: 265047

Revert r265039 "[X86] Merge adjacent stack adjustments in eliminateCallFramePseudoInstr (PR27140)"

I think it might have caused these build breakages:
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/7234/steps/build%20stage%202/logs/stdio
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19566/steps/run%20tests/logs/stdio

llvm-svn: 265046

[X86][SSE] Some basic tests for variable shuffles

We don't really support non-constant shuffle masks, but these tests are for cases where BUILD_VECTOR is made up from vector extracts (as well as undef/zero scalars).

llvm-svn: 265045

lld: accept and ignore _fbsd suffix in emulation name

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

llvm-svn: 265044

Preserve extern_weak linkage in CloneModule.

Only force "extern" linkage if the function used to be a definition
in the source module. Declarations keep their original linkage.

llvm-svn: 265043

[index] Fix regression where ObjC method declarations may mistakenly get indexed as definition.

rdar://25372906

llvm-svn: 265042

[CMake] Provide the ability to skip stripping when generating dSYMs

For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting LLVM_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.

llvm-svn: 265041

[ARM] Expand v1i64 and v2i64 ctpop.

The default is legal, which results in 'Cannot select' errors. This is
triggered during selfhost due to a recent cost model change.

llvm-svn: 265040

[X86] Merge adjacent stack adjustments in eliminateCallFramePseudoInstr (PR27140)

For code such as:

  void f(int, int);
  void g() {
      f(1, 2);
  }

compiled for 32-bit X86 Linux, Clang would previously generate:

  subl    $12, %esp
  subl    $8, %esp
  pushl   $2
  pushl   $1
  calll   f
  addl    $16, %esp
  addl    $12, %esp
  retl

This patch fixes that by merging adjacent stack adjustments in
eliminateCallFramePseudoInstr().

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

llvm-svn: 265039

Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.

Whatever crash it was there to present appears to have been fixed in the
backend now, and it had the nasty side-effect of causing clang to exit(0) and
leave a .o containing goodness knows what even when an error hit.

llvm-svn: 265038

[PGO] Avoid instrumenting constants at value sites

Value profiling should not profile constants and/or constant
expressions when they appear as callees in call instructions.
Constant expressions form when a direct callee has bitcasts or
inttoptr(ptrtint (callee)) nests surrounding it. Value profiling
should avoid instrumenting such cases. Mostly NFC.

llvm-svn: 265037

Change eliminateCallFramePseudoInstr() to return an iterator

This will become necessary in a subsequent change to make this method
merge adjacent stack adjustments, i.e. it might erase the previous
and/or next instruction.

It also greatly simplifies the calls to this function from Prolog-
EpilogInserter. Previously, that had a bunch of logic to resume iteration
after the call; now it just continues with the returned iterator.

Note that this changes the behaviour of PEI a little. Previously,
it attempted to re-visit the new instruction created by
eliminateCallFramePseudoInstr(). That code was added in r36625,
but I can't see any reason for it: the new instructions will obviously
not be pseudo instructions, they will not have FrameIndex operands,
and we have already accounted for the stack adjustment.

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

llvm-svn: 265036

Fix the comment for the function added in r264998.

llvm-svn: 265035

[lit][googletest] Handle upstream gtest output

Summary:
Upstream googletest prints "Running main() from gtest_main.cc" to stdout prior
to running tests. LLVM removed that print statement in r61540. If a user were
to use lit to run tests that use upstream googletest, however, lit
reports "Running main()" as an invalid test name.

To avoid such a failure, add an extra conditional to `formats/googletest.py`.
Also add tests to demonstrate the modified behavior.

Reviewers: abdulras, ddunbar

Subscribers: ddunbar, llvm-commits, kastiglione

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

llvm-svn: 265034

[clang-tidy] Add a new checker to detect missing comma in initializer list.

Summary:
This checker is able to detect missing comma in
an array of string literals.

```
  const char* A[] = {
    "abc",
    "def"   // missing comma (no compiler warnings)
    "ghi",
  };
```

The ratio of false-positive is reduced by restricting the
size of the array considered and the ratio of missing
comma.

To validate the quantity of false positive, the checker
was tried over LLVM and chromium code and detected these
cases:

[[ http://reviews.llvm.org/D18454 | http://reviews.llvm.org/D18454 ]]
[[https://codereview.chromium.org/1807753002/ | https://codereview.chromium.org/1807753002/]]
[[https://codereview.chromium.org/1826193002/ | https://codereview.chromium.org/1826193002/]]
[[https://codereview.chromium.org/1805713002/ | https://codereview.chromium.org/1805713002/]]

Reviewers: alexfh

Subscribers: LegalizeAdulthood, szdominik, xazax.hun, cfe-commits

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

llvm-svn: 265033

[lanai] isBrImm should accept any non-constant immediate.

isBrImm should accept any non-constant immediate. Previously it was only accepting LanaiMCExpr ones which was wrong.

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

llvm-svn: 265032

[PPC] basic support for Power 9 direct move instructions

http://reviews.llvm.org/D18097

Initial support does not include any patterns to generate this instructions

llvm-svn: 265031

[PGO] use emplace_back. NFC.

Use emplace_back instead of push_back for simplicity.

llvm-svn: 265030

[x86] use SSE/AVX ops for non-zero memsets (PR27100)

Move the memset check down to the CPU-with-slow-SSE-unaligned-memops case: this allows fast
targets to take advantage of SSE/AVX instructions and prevents slow targets from stepping
into a codegen sinkhole while trying to splat a byte into an XMM reg.

Follow-on bugs exposed by the current codegen are:
https://llvm.org/bugs/show_bug.cgi?id=27141
https://llvm.org/bugs/show_bug.cgi?id=27143

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

llvm-svn: 265029

[AMDGPU] enable few disassembler tests that were mistakenly marked as FIXME.

llvm-svn: 265028

More checks in win32-seh-nested-finally.ll after comment on r264966

llvm-svn: 265027

[PowerPC] Attempt to fix fast-isel-i64offset.ll failure

The test case added in r265023 is failing on ninja-x64-msvc-RA-centos6.
Update the test to make less specific assumptions on code generation.

llvm-svn: 265026

Minor code cleanup /NFC

llvm-svn: 265025

Don't use potentially invalidated iterator

If the lhs is evaluated before the rhs, FuncletI's operator-> can trigger the

  assert(isHandleInSync() && "invalid iterator access!");

at include/llvm/ADT/DenseMap.h:1061.  (Happens e.g. when compiled with GCC 6.)

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

llvm-svn: 265024

[PowerPC] Correctly compute 64-bit offsets in fast isel

PPCSimplifyAddress contains this code:

  IntegerType *OffsetTy = ((VT == MVT::i32) ? Type::getInt32Ty(*Context)
                                            : Type::getInt64Ty(*Context));

to determine the type to be used for an index register, if one needs
to be created.  However, the "VT" here is the type of the data being
loaded or stored, *not* the type of an address.  This means that if
a data element of type i32 is accessed using an index that does not
not fit into 32 bits, a wrong address is computed here.

Note that PPCFastISel is only ever used on 64-bit currently, so the type
of an address is actually *always* MVT::i64.  Other parts of the code,
even in this same PPCSimplifyAddress routine, already rely on that fact.
Thus, this patch changes the code to simply unconditionally use
Type::getInt64Ty(*Context) as OffsetTy.

llvm-svn: 265023

[PowerPC] Basic support for P9 atomic loads and stores

This patch corresponds to review:
http://reviews.llvm.org/D18032

This patch provides asm implementation for the following instructions:
lwat, ldat, stwat, stdat, ldmx, mcrxrx

llvm-svn: 265022

[AArch64] Handle missing store pair opportunity

Summary:
This change will handle missing store pair opportunity where the first store
instruction stores zero followed by the non-zero store. For example, this change
will convert :

  str wzr, [x8]
  str w1, [x8, #4]
into:
  stp wzr, w1, [x8]

Reviewers: jmolloy, t.p.northover, mcrosier

Subscribers: flyingforyou, aemerson, rengolin, mcrosier, llvm-commits

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

llvm-svn: 265021

[PowerPC] Remove incorrect use of COPY_TO_REGCLASS in fast isel

The fast isel pass currently emits a COPY_TO_REGCLASS node to convert
from a F4RC to a F8RC register class during conversion of a
floating-point number to integer. There is actually no support in the
common code instruction printers to emit COPY_TO_REGCLASS nodes, so the
PowerPC back-end has special code there to simply ignore
COPY_TO_REGCLASS.

This is correct *if and only if* the source and destination registers of
COPY_TO_REGCLASS are the same (except for the different register class).
But nothing guarantees this to be the case, and if the register
allocator does end up allocating source and destination to different
registers after all, the back-end simply generates incorrect code. I've
included a test case that shows such incorrect code generation.

However, it seems that COPY_TO_REGCLASS is actually not intended to be
used at the MI layer at all. It is used during SelectionDAG, but always
lowered to a plain COPY before emitting MI. Other back-end's fast isel
passes never emit COPY_TO_REGCLASS at all. I suspect it is simply wrong
for the PowerPC back-end to emit it here.

This patch changes the PowerPC back-end to directly emit COPY instead of
COPY_TO_REGCLASS and removes the special handling in the instruction
printers.

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

llvm-svn: 265020

[mips] Range check simm16

Summary:
There are too many instructions to exhaustively test so addiu and lwc2 are
used as representative examples.

It should be noted that many memory instructions that should have simm16
range checking do not because it is also necessary to support the macro
of the same name which accepts simm32. The range checks for these occur in
the macro expansion.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265019

[mips] Range check simm11 and mem_simm11.

Summary:
ldc2/sdc2 now emit slightly worse diagnostics for MIPS-I. The problem
is that they don't trigger the custom parser because all the candidates
are disabled by feature bits. On all other subtargets, the diagnostics are
accurate but are subject to the usual issues of needing to report multiple
ways to correct the code (e.g. smaller offset, enable a CPU feature) but
only being able to report one error.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265018

Don't vary debug info for lldb-server tests

Summary:
Debug info is used only by the client and lldb-server tests do not even have the client component
running, as they communicate with the server directly. Therefore, running the tests for each
debug info type is unnecessarry.

This adds general ability to mark a test class as not dependent on debug info, and marks all
lldb-server tests as such.

Reviewers: tberghammer, tfiala

Subscribers: lldb-commits

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

llvm-svn: 265017

[IFUNC] Introduce GlobalIndirectSymbol as a base class for alias and ifunc

This patch is a part of http://reviews.llvm.org/D15525

GlobalIndirectSymbol class contains common implementation for both
aliases and ifuncs. This patch should be NFC change that just prepare
common code for ifunc support.

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

llvm-svn: 265016

[AMDGPU] Disassembler: support for DPP

Review: http://reviews.llvm.org/D18642
llvm-svn: 265015

[mips] Split mem_msa into range checked mem_simm10 and mem_simm10_lsl[123]

Summary:
Also, made test_mi10.s formatting consistent with the majority of the
MC tests.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265014

Prevent X86ISelLowering from merging volatile loads

Change isConsecutiveLoads to check that loads are non-volatile as this
is a requirement for any load merges. Propagate change to two callers.

Reviewers: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 265013

Pass a const SymbolBody to needsGot. NFC.

llvm-svn: 265012