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

llvm-svn: 315610

Because it was a redundant accessor to Symbol's public member.

llvm-svn: 315609

Differential Revision: https://reviews.llvm.org/D38747

llvm-svn: 315608

Reviewers: RKSimon, zvi, igorb

Reviewed By: RKSimon

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D38781

llvm-svn: 315607

We were missing most of the "core" aliases as well as skylake, cannonlake, and knights landing.

llvm-svn: 315606

Fix the gtest dependency to be included in DEPS only, rather than
in COMPILE_DEPS + DEPS. The former variable is apparently used to
provide unconditional dependencies, while the latter are only used
for non-standalone builds. Since they are concatenated, specifying gtest
in both is redundant. Furthermore, including it in COMPILE_DEPS causes
build failure for standalone builds where 'gtest' target is not present.

Differential Revision: https://reviews.llvm.org/D38839

llvm-svn: 315605

Fix typo in variable assignment inside sanitizer_test_compile() that
resulted in TEST_DEPS parameter not being included in the clang_compile()
call. Spotted by George Karpenkov in D38444.

Differential Revision: https://reviews.llvm.org/D38838

llvm-svn: 315604

Reviewers: kcc, bogner

Reviewed By: kcc

Subscribers: cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D38853

llvm-svn: 315603

llvm-svn: 315602

WMMA = "Warp Level Matrix Multiply-Accumulate".
These are the new instructions introduced in PTX6.0 and available
on sm_70 GPUs.

Differential Revision: https://reviews.llvm.org/D38645

llvm-svn: 315601

Attempt 3 to work around bugs in FPO data with funclets.

llvm-svn: 315600

Building with BUILD_SHARED_LIBS makes it tricky to copy around
executables at will, since they won't be able to find the LLVM
libraries any more. This makes testing a feature that's based on the
executable name problematic, so we'll just disable these two tests in
that configuration.

We could potentially fix this by symlinking the lib directory into the
test directory, but that wouldn't work on windows, and losing testing
on windows would be far worse than losing testing on a configuration
that's barely even supported.

llvm-svn: 315599

Differential Revision: https://reviews.llvm.org/D38633

llvm-svn: 315598

In r315079 I added a check for the ERROR_CALL_NOT_IMPLEMENTED error
code, but it turns out earlier versions of Wine just returned false
without setting any error code.

This patch handles the unset error code case.

llvm-svn: 315597

llvm-svn: 315596

Poison allows us to return a better result than undef.

llvm-svn: 315595

[X86] Use -ffreestanding instead of using the mm_malloc.h include guard hack on more of the builtin tests.

llvm-svn: 315594

This is r315288 & r315294, which were reverted due to stage2 bot
failures.

Summary:
This updates the SCCP solver to use of the ValueElement lattice for
parameters, which provides integer range information. The range
information is used to remove unneeded icmp instructions.

For the following function, f() can be optimized to `ret i32 2` with
this change

  source_filename = "sccp.c"
  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"

  ; Function Attrs: norecurse nounwind readnone uwtable
  define i32 @main() local_unnamed_addr #0 {
  entry:
    %call = tail call fastcc i32 @f(i32 1)
    %call1 = tail call fastcc i32 @f(i32 47)
    %add3 = add nsw i32 %call, %call1
    ret i32 %add3
  }

  ; Function Attrs: noinline norecurse nounwind readnone uwtable
  define internal fastcc i32 @f(i32 %x) unnamed_addr #1 {
  entry:
    %c1 = icmp sle i32 %x, 100

    %cmp = icmp sgt i32 %x, 300
    %. = select i1 %cmp, i32 1, i32 2
    ret i32 %.
  }

  attributes #1 = { noinline }

Reviewers: davide, sanjoy, efriedma, dberlin

Reviewed By: davide, dberlin

Subscribers: mcrosier, gberry, mssimpso, dberlin, llvm-commits

Differential Revision: https://reviews.llvm.org/D36656

llvm-svn: 315593

Add profitability checks for modifying counted loops to use the mtctr instruction.

The latency of mtctr is only justified if there are more than 4 comparisons that
will be removed as a result.  Usually counted loops are formed relatively early
and before unrolling, so most low trip count loops often don't survive.  However
we want to ensure that if they do, we do not mistakenly update them to mtctr loops.

Use CodeMetrics to ensure we are only doing this for small loops with small trip counts.

Differential Revision: https://reviews.llvm.org/D38212

llvm-svn: 315592

Summary:
The interpolation mode workaround ensures that at least one
interpolation mode is enabled in PSInputAddr. It does not also check
PSInputEna on the basis that the user might enable bits in that
depending on run-time state.

However, for amdpal os type, the user does not enable some bits after
compilation based on run-time states; the register values being
generated here are the final ones set in the hardware. Therefore, apply
the workaround to PSInputAddr and PSInputEnable together. (The case
where a bit is set in PSInputAddr but not in PSInputEnable is where the
frontend set up an input arg for a particular interpolation mode, but
nothing uses that input arg. Really we should have an earlier pass that
removes such an arg.)

Reviewers: arsenm, nhaehnle, dstuttard

Subscribers: kzhuravl, wdng, yaxunl, t-tye, llvm-commits

Differential Revision: https://reviews.llvm.org/D37758

llvm-svn: 315591

Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.

Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.

Differential Revision: https://reviews.llvm.org/D38406

llvm-svn: 315590

This is a follow-up suggested in D37534.
Patch by Yulia Koval.

llvm-svn: 315589

The number 131076 didn't show up anywhere in the test.

llvm-svn: 315588

[X86][SSE] Pull out repeated INSERT_VECTOR_ELT code from LowerBUILD_VECTOR v16i8/v8i16 insertion. NFCI.

llvm-svn: 315587

function params.

Codegen could crash if the array section base expression is the
function parameter.

llvm-svn: 315586

The address of the .got section is not relevant for the test.

llvm-svn: 315585

It doesn't make sense to link from an alloc section to a non alloc
one as we were doing.

This matches the behavior of both gold and bfd.

llvm-svn: 315584

Summary:
This first part just prepares the grounds for part 2 and doesn't add any new
functionality. It mostly consists of small refactors:
- move the `pthread.h` include higher as it will be used in the headers;
- use `errno.h` in `scudo_allocator.cpp` instead of the sanitizer one, update
  the `errno` assignments accordingly (otherwise it creates conflicts on some
  platforms due to `pthread.h` including `errno.h`);
- introduce and use `getCurrentTSD` and `setCurrentTSD` for the shared TSD
  model code;

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: llvm-commits, srhines

Differential Revision: https://reviews.llvm.org/D38826

llvm-svn: 315583

llvm-svn: 315582

The typo in r315556 disabled the cfi-verify unit tests from building
unconditionally, have it correctly check for the X86 target.

llvm-svn: 315581

This reverts r315057. The revision introduces assertion failures:
assertion failed at llvm/tools/clang/include/clang/Basic/SourceManager.h:428 in
const clang::SrcMgr::ExpansionInfo &clang::SrcMgr::SLocEntry::getExpansion()
const: isExpansion() && "Not a macro expansion SLocEntry!"
Stack trace:
    __assert_fail
    clang::SrcMgr::SLocEntry::getExpansion()
    clang::SourceManager::getExpansionLocSlowCase()
    clang::SourceManager::getExpansionLoc()
    clang::Lexer::getRawToken()
    clang::tidy::readability::NamespaceCommentCheck::check()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::MatchVisitor::visitMatch()
    clang::ast_matchers::internal::BoundNodesTreeBuilder::visitMatches()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchWithFilter()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchDispatch()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::ast_matchers::MatchFinder::matchAST()
    clang::MultiplexConsumer::HandleTranslationUnit()
    clang::ParseAST()
    clang::FrontendAction::Execute()
    clang::CompilerInstance::ExecuteAction()
    clang::tooling::FrontendActionFactory::runInvocation()
    clang::tooling::ToolInvocation::runInvocation()
    clang::tooling::ToolInvocation::run()

Still working on an isolated test case.

llvm-svn: 315580

MachineInstr::isIdenticalTo has a lot of logic for dealing with register
Defs (i.e. deciding whether to take them into account or ignore them).
This logic gets things wrong in some obscure cases, for instance if an
operand is not a Def for both the current MI and the one we are
comparing to.

I'm not sure if it's possible for this to happen for regular register
operands, but it may happen in the ARM backend for special operands
which use sentinel values for the register (i.e. 0, which is neither a
physical register nor a virtual one).

This causes MachineInstrExpressionTrait::isEqual (which uses
MachineInstr::isIdenticalTo) to return true for the following
instructions, which are the same except for the fact that one sets the
flags and the other one doesn't:
%1114 = ADDrsi %1113, %216, 17, 14, _, def _
%1115 = ADDrsi %1113, %216, 17, 14, _, _

OTOH, MachineInstrExpressionTrait::getHashValue returns different values
for the 2 instructions due to the different isDef on the last operand.
In practice this means that when trying to add those instructions to a
DenseMap, they will be considered different because of their different
hash values, but when growing the map we might get an assertion while
copying from the old buckets to the new buckets because isEqual
misleadingly returns true.

This patch makes sure that isEqual and getHashValue agree, by improving
the checks in MachineInstr::isIdenticalTo when we are ignoring virtual
register definitions (which is what the Trait uses). Firstly, instead of
checking isPhysicalRegister, we use !isVirtualRegister, so that we cover
both physical registers and sentinel values. Secondly, instead of
checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo,
which checks isReg, isSubReg and isDef, which are the same values that
the hash function uses to compute the hash.

Note that the function is symmetric with this change, since if the
current operand is not a Def, we check MachineOperand::isIdenticalTo,
which returns false if the operands have different isDef's.

Differential Revision: https://reviews.llvm.org/D38789

llvm-svn: 315579

in C.

If we try to get the lvalue for thread_id variables in inlined regions,
we did not use the correct version of function. Fixed this bug by adding
overrided version of the function getThreadIDVariableLValue for inlined
regions.

llvm-svn: 315578

Summary:
Make the ProtocolHandlers glue between JSONRPCDispatcher and
ClangdLSPServer generic.
Eliminate small differences between methods, de-emphasize the unimportant
distinction between notifications and methods.

ClangdLSPServer is no longer responsible for producing a complete
JSON-RPC response, just the JSON of the result object. (In future, we
should move that JSON serialization out, too).
Handler methods now take a context object that we may hang more
functionality off in the future.

Added documentation to ProtocolHandlers.

Reviewers: ilya-biryukov, bkramer

Reviewed By: ilya-biryukov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D38464

llvm-svn: 315577

While this shouldn't be necessary anymore, we have cases where we run
into the assertion below, i.e. cases with two non-fragment entries for the
same variable at different frame indices.

This should be fixed, but for now, we should revert to a version that
does not trigger asserts.

llvm-svn: 315576

This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial ways. Eventually, we will consider each of these
cases to make sure the TBAA information is correct and not too
conservative. For now, we just fall back to generating TBAA info
from the access type.

This patch should not bring in any functional changes.

This is part of D38126 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D38733

llvm-svn: 315575

Restore the file extension. Make the namespace longer than the
ShortNamespaceLines so that the check triggers.

llvm-svn: 315574

llvm-svn: 315573

SVal::getAsSymbol(bool IncludeBaseRegions): Follow clang/StaticAnalyzer/Core/PathSensitive/SVals.h, s/IncludeBaseRegion/IncludeBaseRegions/g [-Wdocumentation]

llvm-svn: 315572

This fixes the "switch statement contains 'default' but no 'case' labels"
warnings in table-generated code introduced in r315295.

llvm-svn: 315571