[AMDGPU][MC] Corrected checks for DS offset0 range

See bug 40889: https://bugs.llvm.org/show_bug.cgi?id=40889

Reviewers: artem.tamazov, arsenm

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

llvm-svn: 356576

[clang-format] structured binding in range for detected as Objective C

Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++

Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160

$ clang-format.exe test.h
Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format

--- test.h --
```

std::vector<std::pair<std::string,std::string>> C;

void foo()
{
   for (auto && [A,B] : C)
   {
       std::string D = A + B;
   }
}
```
The following code fixes this issue of incorrect detection

Reviewers: djasper, klimek, JonasToth, reuk

Reviewed By: klimek

Subscribers: cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 356575

[NFC] Fix a couple of typos in libc++'s __config

llvm-svn: 356574

Fix UUID decoding from minidump files

This patch fixes:

UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files.
UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules.
UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes.
Added tests for PDB70 and ELF build ID based CvRecords.

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

llvm-svn: 356573

[CGP] fix formatting; NFC

llvm-svn: 356572

[OpenCL] Generate 'unroll.enable' metadata for  __attribute__((opencl_unroll_hint))

Summary:
[OpenCL] Generate 'unroll.enable' metadata for  __attribute__((opencl_unroll_hint))

For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller
will try to fully unroll a loop unless the trip count is not known at compile time.
In that case for '.full' metadata no unrolling will be processed, while for '.enable'
the loop will be partially unrolled with a heuristically chosen unroll factor.

See: docs/LanguageExtensions.rst

From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html

    __attribute__((opencl_unroll_hint))
    for (int i=0; i<2; i++)
    {
        ...
    }

In the example above, the compiler will determine how much to unroll the loop.

Before the patch for  __attribute__((opencl_unroll_hint)) was generated metadata
!{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how
much to unroll the loop.

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: zzheng, dmgreen, jdoerfert, cfe-commits, asavonic, AlexeySotkin

Tags: #clang

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

llvm-svn: 356571

[clang][OpeMP] Model OpenMP structured-block in AST (PR40563)

Summary:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3:
```
structured block

For C/C++, an executable statement, possibly compound, with a single entry at the
top and a single exit at the bottom, or an OpenMP construct.

COMMENT: See Section 2.1 on page 38 for restrictions on structured
blocks.
```
```
2.1 Directive Format

Some executable directives include a structured block. A structured block:
• may contain infinite loops where the point of exit is never reached;
• may halt due to an IEEE exception;
• may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
_Noreturn specifier (in C) or a noreturn attribute (in C/C++);
• may be an expression statement, iteration statement, selection statement, or try block, provided
that the corresponding compound statement obtained by enclosing it in { and } would be a
structured block; and

Restrictions
Restrictions to structured blocks are as follows:
• Entry to a structured block must not be the result of a branch.
• The point of exit cannot be a branch out of the structured block.
C / C++
• The point of entry to a structured block must not be a call to setjmp().
• longjmp() and throw() must not violate the entry/exit criteria.
```

Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`,
in the same sense as with the normal `noexcept` functions in C++.
I.e. if throw happens, and it attempts to travel out of the `noexcept` function
(here: out of the current structured-block), then the program terminates.

Now, one of course can say that since it is explicitly prohibited by the Specification,
then any and all programs that violate this Specification contain undefined behavior,
and are unspecified, and thus no one should care about them. Just don't write broken code /s

But i'm not sure this is a reasonable approach.
I have personally had oss-fuzz issues of this origin - exception thrown inside
of an OpenMP structured-block that is not caught, thus causing program termination.
This issue isn't all that hard to catch, it's not any particularly different from
diagnosing the same situation with the normal `noexcept` function.

Now, clang static analyzer does not presently model exceptions.
But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check,
and it is even refactored as a `ExceptionAnalyzer` class for reuse.
So it would be trivial to use that analyzer to check for
exceptions escaping out of OpenMP structured blocks. (D59466)

All that sounds too great to be true. Indeed, there is a caveat.
Presently, it's practically impossible to do. To check a OpenMP structured block
you need to somehow 'get' the OpenMP structured block, and you can't because
it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation.

Now, it is of course possible to write e.g. some AST matcher that would e.g.
match every OpenMP executable directive, and then return the whatever `Stmt` is
the structured block of said executable directive, if any.
But i said //practically//. This isn't practical for the following reasons:
1. This **will** bitrot. That matcher will need to be kept up-to-date,
   and refreshed with every new OpenMP spec version.
2. Every single piece of code that would want that knowledge would need to
   have such matcher. Well, okay, if it is an AST matcher, it could be shared.
   But then you still have `RecursiveASTVisitor` and friends.
   `2 > 1`, so now you have code duplication.

So it would be reasonable (and is fully within clang AST spirit) to not
force every single consumer to do that work, but instead store that knowledge
in the correct, and appropriate place - AST, class structure.

Now, there is another hoop we need to get through.
It isn't fully obvious //how// to model this.
The best solution would of course be to simply add a `OMPStructuredBlock` transparent
node. It would be optimal, it would give us two properties:
* Given this `OMPExecutableDirective`, what's it OpenMP structured block?
* It is trivial to  check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`)

But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`.
(even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween).
So i'm not sure whether or not we could re-create AST statements after they were already created?
There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12
```
1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity.
2. You will need to support serialization/deserialization.
3. You will need to support template instantiation.
4. You will need to support codegen and take this new construct to account in each OpenMP directive.
```

Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts.

Part 1:
* Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class,
  that will tell whether this directive is stand-alone or not, as per the spec.
  We need it because we can't just check for the existance of associated statements,
  see code comment.
* Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself,
  that assert that this is not a stand-alone directive, and either return the correct loop body
  if this is a loop-like directive, or the captured statement.
This way, given an `OMPExecutableDirective`, we can get it's structured block.
Also, since the knowledge is ingrained into the clang OpenMP implementation,
it will not cause any duplication, and //hopefully// won't bitrot.

Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach.

Thus, there is a second part needed:
* How can we check whether a given `Stmt*` is `OMPStructuredBlock`?
Well, we can't really, in general. I can see this workaround:
```
class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> {
  using Base = RecursiveASTVisitor<FunctionASTVisitor>;
public:
  bool VisitOMPExecDir(OMPExecDir *D) {
    OmpStructuredStmts.emplace_back(D.getStructuredStmt());
  }
  bool VisitSOMETHINGELSE(???) {
    if(InOmpStructuredStmt)
      HI!
  }
  bool TraverseStmt(Stmt *Node) {
    if (!Node)
      return Base::TraverseStmt(Node);
    if (OmpStructuredStmts.back() == Node)
      ++InOmpStructuredStmt;
    Base::TraverseStmt(Node);
    if (OmpStructuredStmts.back() == Node) {
      OmpStructuredStmts.pop_back();
      --InOmpStructuredStmt;
    }
    return true;
  }
  std::vector<Stmt*> OmpStructuredStmts;
  int InOmpStructuredStmt = 0;
};
```
But i really don't see using it in practice.
It's just too intrusive; and again, requires knowledge duplication.

.. but no. The solution lies right on the ground.
Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself?
This does not appear to have any impact on the memory footprint of the clang AST,
since it's just a single extra bit in the bitfield. At least the static assertions don't fail.
Thus, indeed, we can achieve both of the properties without a new AST node.

We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`,
by just calling the `getStructuredBlock()` that we just added.
Test coverage that demonstrates all this has been added.

This isn't as great with serialization though. Most of it does not use abbrevs,
so we do end up paying the full price (4 bytes?) instead of a single bit.
That price, of course, can be reclaimed by using abbrevs.
In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly.

I'm not seeing a third solution. If there is one, it would be interesting to hear about it.
("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.)

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]].

Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr

Reviewed By: ABataev, gribozavr

Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits

Tags: #clang, #openmp

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

llvm-svn: 356570

[NFC][clang][astdump] Some baseline tests for OpenMP

Summary:
Split off from D59214.
Not a fully exhaustive test coverage, but better than what there currently is.

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

llvm-svn: 356569

Fix sanitizer failures for 356550.

Mark bcmp as having optimized codegen, so that asan can detect it and
mark users as nobuiltin.

llvm-svn: 356568

gn build: Add build files for some clang-tools-extra

Adds clang-change-namespace, clang-move, clang-query,
clang-reorder-fields.

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

llvm-svn: 356567

[CGP] convert chain of 'if' to 'switch'; NFC

This should be extended, but CGP does some strange things,
so I'm intentionally not changing the potential order of
any transforms yet.

llvm-svn: 356566

Reland r356547 after fixing the tests for Linux.

[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.

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

llvm-svn: 356565

[ASTImporter] Remove obsolete function ImportTemplateParameterList.

Summary:
The ASTNodeImporter::ImportTemplateParameterList is replaced by a
template specialization of 'import' that already exists and does
(almost) the same thing.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: martong

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

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

llvm-svn: 356564

gn build: Merge r356508

llvm-svn: 356563

[libc++] Do not force going through xcrun to find Clang in the macOS CI scripts

It should be possible to run those CI scripts with different compilers
by simply exporting a different CXX environment variable.

llvm-svn: 356562

[AMDGPU][MC][GFX9] Added support of operands shared_base, shared_limit, private_base, private_limit, pops_exiting_wave_id

See bug 39297: https://bugs.llvm.org/show_bug.cgi?id=39297

Reviewers: artem.tamazov, arsenm, rampitec

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

llvm-svn: 356561

gn build: Merge r356519

llvm-svn: 356560

[CGP][x86] add tests for usubo regression (PR41129); NFC

llvm-svn: 356559

[libc++] Mark <filesystem> tests as failing when the dylib doesn't support filesystem

This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.

This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.

llvm-svn: 356558

Follow up of rL356555

Pacify buildbot that complained about a member function not marked with
override.

llvm-svn: 356557

[scudo][standalone] Add error reports

Summary:
This change adds fatal error messages for various error conditions that
will be added later in the code.
This also addresses a `TODO` now that we have `reportCheckFailed` (which
lead me to notice a few variables that were not cased properly so I
changed that as well).

Reviewers: morehouse, hctim, vitalybuka

Reviewed By: morehouse, hctim, vitalybuka

Subscribers: mgorny, delcypher, jfb, jdoerfert, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 356556

[TTI] getMemcpyCost

This adds new function getMemcpyCost to TTI so that the cost of a memcpy can be
modeled and queried. The default implementation returns Expensive, but targets
can override this function to model the cost more accurately.

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

llvm-svn: 356555

[llvm-objcopy] - Use replaceSectionReferences to update the sections for symbols in symbol table.

If the compression was used and we had a symbol not involved in relocation,
we never updated its section and it was silently removed from the output.

Differential revision: https://reviews.llvm.org/D59542

llvm-svn: 356554

Revert rL356547 : [clang-tidy] Cosmetic fix
Differential Revision: https://reviews.llvm.org/D57662
........
[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.

Differential Revision: https://reviews.llvm.org/D57662
........
Reverted to fix buildbot: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/45547/steps/test/logs/stdio

llvm-svn: 356553

Remove out of date comment. NFCI.

DAGCombiner::convertBuildVecZextToZext just requires the extractions to be sequential, they don't have to start from 0'th index.

llvm-svn: 356552

Correct this attribute group documentation to have a heading, which fixes the docs builder.

llvm-svn: 356551

[ExpandMemCmp] Trigger on bcmp too.

Summary: Fixes 41150.

Reviewers: gchatelet

Subscribers: hiraditya, llvm-commits, ckennelly, sbenza, jyknight

Tags: #llvm

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

llvm-svn: 356550

[X86] Use getConstantOperandAPInt to detect out-of-range shifts.

llvm-svn: 356549

[clang-tidy] Cosmetic fix

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

llvm-svn: 356548

[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.

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

llvm-svn: 356547

[X86] Remove X86 specific dag nodes for RDTSC/RDTSCP/RDPMC. NFCI

This patch removes the following dag node opcodes from namespace X86ISD:

RDTSC_DAG,
RDTSCP_DAG,
RDPMC_DAG

The logic that expands RDTSC/RDPMC/XGETBV intrinsics is basically the same. The
only differences are:

    RDTSC/RDTSCP don't implicitly read ECX.
    RDTSCP also implicitly writes ECX.

I moved the common expansion logic into a helper function with the goal to get
rid of code repetition. That helper is now used for the expansion of
RDTSC/RDTSCP/RDPMC/XGETBV intrinsics.

No functional change intended.

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

llvm-svn: 356546

Fix -Wdocumentation warning. NFCI.

llvm-svn: 356543

[perf][DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces"

Summary: Fix the build failure when perf jit is enabled

Reviewers: avl, dblaikie

Reviewed By: avl

Subscribers: modocache, llvm-commits

Tags: #llvm

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

llvm-svn: 356542

[clangd] Print arguments in template specializations

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

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

llvm-svn: 356541

[AMDGPU] Allow MIMG with no uses in adjustWritemask in isel

Summary:
If an MIMG instruction has managed to get through to adjustWritemask in isel but
has no uses (and doesn't enable TFC) then prevent an assertion by not attempting
to adjust the writemask.

The instruction will be removed anyway.

Change-Id: I9a5dba6bafe1f35ac99c1b73df390936e2ac27a7

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, llvm-commits

Tags: #llvm

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

llvm-svn: 356540

Python 2/3 compatibility

This should be the only change required to have lld's python code base compatible with both Python 2 and Python 3

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

llvm-svn: 356538

[X86] Separate PentiumPro and i686. They aren't aliases in the backend.

PentiumPro has HasNOPL set in the backend. i686 does not.

Despite having a function that looks like it canonicalizes alias names. It
doesn't seem to be called. So I don't think this is a functional change. But its
good to be consistent between the backend and frontend.

llvm-svn: 356537

[instcombine] Add todos describing missing transforms for masked.* intrinsics

llvm-svn: 356536

[X86] Remove X32 check lines from a test that doesn't have an X32 FileCheck prefix. Regenerate the test using update_llc_test_checks. NFC

llvm-svn: 356535

Retry to add workaround to build scoped enums with VS2015. NFCI.

We need this as we still have internal build bots on VS2015.

llvm-svn: 356534

Revert "Add workaround to build scoped enums with VS2015. NFCI."

This reverts commit 6080a6fb1949a2bdf053245d6062c7bf58dae7a6 (r356532).

Clang does not accept this syntax, so reverting this until I can find something that works across all compilers.

llvm-svn: 356533

Add workaround to build scoped enums with VS2015. NFCI.

We need this as we still have internal build bots on VS2015.

llvm-svn: 356532

[X86] Re-disable cmpxchg16b for 32-bit mode assembly parsing.

This was broken recently when I factored the 64 bit mode check into hasCmpxchg16 without thinking about the AssemblerPredicate.

llvm-svn: 356531

Replace tok::angle_string_literal with new tok::header_name.

Use the new kind for both angled header-name tokens and for
double-quoted header-name tokens.

This is in preparation for C++20's context-sensitive header-name token
formation rules.

llvm-svn: 356530

[builtins] Divide shouldn't underflow if rounded result would be normal.

We were treating certain edge cases that are actually normal as denormal
results, and flushing them to zero; we shouldn't do that. Not sure this
is the cleanest way to implement this edge case, but I wanted to avoid
adding any code on the common path.

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

llvm-svn: 356529

[libc++] Flag file_clock test as expected to fail with ASAN

This silences a known issue, as can be seen by looking at similar
tests for other clocks, like time.clock.steady/consistency.pass.cpp.

llvm-svn: 356528

[ARM] Make sure to save/restore LR when we use tBfar.

This change does two things. One, it ensures compilation will abort
instead of miscompiling if ARMFrameLowering::determineCalleeSaves
chooses not to save LR in a case where it's necessary.  Two, it changes
the way we estimate the size of a function to be more conservative in
the presence of constant pool entries and jump tables.

EstimateFunctionSizeInBytes probably still isn't really conservative
enough, but I'm not sure how we can come up with a reliable estimate
before constant islands runs.

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

llvm-svn: 356527

[AArch64][GlobalISel] Add an optimization to select vector DUP instructions.

This adds pattern matching for the insert+shufflevector sequence so we can
generate dup instructions instead of the current TBL sequence.

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

llvm-svn: 356526

[AArch64][GlobalISel] Make v4s32 G_IMPLICIT_DEF legal.

llvm-svn: 356525

Remove MSVC compat hack since the inline keyword was added in 2015

Our minimum MSVC toolchain requirement is greater than 2015, so we don't
need this conditional macro anymore.  New versions of MSVC apparently
have a header, xkeycheck.h, to check that keywords haven't been
redefined.

Fixes PR41144

llvm-svn: 356524

[libc++] Complete the ABI changelog after landing <filesystem> in the dylib

llvm-svn: 356523

[Remarks] Fix gcc build for r356519

Fails here:
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/20046/steps/build%20stage%201/logs/stdio

llvm-svn: 356522

[DwarfDebug] Add triple to test.

llvm-svn: 356521

[InstSimplify] Add additional cmp of abs without nsw tests; NFC

llvm-svn: 356520

Reland "[Remarks] Add a new Remark / RemarkParser abstraction"

This adds a Remark class that allows us to share code when working with
remarks.

The C API has been updated to reflect this. Instead of the parser
generating C structs, it's now using a C++ object that is used through
opaque pointers in C. This gives us much more flexibility on what
changes we can make to the internal state of the object and interacts
much better with scenarios where the library is used through dlopen.

* C API updates:
  * move from C structs to opaque pointers and functions
  * the remark type is now an enum instead of a string
* unit tests updates:
  * use mostly the C++ API
  * keep one test for the C API
  * rename to YAMLRemarksParsingTest
* a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute.
* a new error message was added: "expected a remark tag."
* llvm-opt-report has been updated to use the C++ parser instead of the
C API

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

Original llvm-svn: 356491

llvm-svn: 356519

[libc++] Build <filesystem> support as part of the dylib

Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.

Unlike the previous attempt (r356500), this doesn't remove all the
filesystem tests.

Reviewers: mclow.lists, EricWF, serge-sans-paille

Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits

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

llvm-svn: 356518

Fix CodeGen/arm64-microsoft-status-reg.cpp test

Summary: This test is failing after r356499 (verified with `ninja check-clang-codegen`). Update the register selection used in the test from x0 to x8.

Reviewers: arsenm, MatzeB, efriedma

Reviewed By: efriedma

Subscribers: efriedma, wdng, javed.absar, kristof.beyls, cfe-commits

Tags: #clang

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

llvm-svn: 356517

Revert r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"

Due to buildbot failures (LLD tests).

llvm-svn: 356516

Add a spelling of pass_object_size that uses __builtin_dynamic_object_size

The attribute pass_dynamic_object_size(n) behaves exactly like
pass_object_size(n), but instead of evaluating __builtin_object_size on calls,
it evaluates __builtin_dynamic_object_size, which has the potential to produce
runtime code when the object size can't be determined statically.

Differential revision: https://reviews.llvm.org/D58757

llvm-svn: 356515

[DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5.

Nothing prevents entries from being bigger than the 16 bit size field in
Dwarf < 5. For entries that are too big, just emit an empty entry
instead of crashing.

This fixes PR41038.

Reviewers: probinson, aprantl, davide

Reviewed By: probinson

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

llvm-svn: 356514

[OPENMP]Warn if the different allocator is used for the variable.

If the allocator was specified for the variable and next one is found
with the different allocator, the warning is emitted, and the allocator
is ignored.

llvm-svn: 356513

[libc++] Speed up certain locale functions on Windows

The issue is that __libcpp_locale_guard makes some slow calls to setlocale().
This change avoids using __libcpp_locale_guard in snprintf_l().

Fixes https://bugs.llvm.org/show_bug.cgi?id=41131

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

llvm-svn: 356512

[TailCallElim] Add tailcall elimination pass to LTO pipelines

LTO provides additional opportunities for tailcall elimination due to
link-time inlining and visibility of nocapture attribute. Testing showed
negligible impact on compilation times.

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

llvm-svn: 356511

Demanded elements support for masked.load and masked.gather

Teach instcombine to propagate demanded elements through a masked load or masked gather instruction. This is in the broader context of improving vector pointer instcombine under https://reviews.llvm.org/D57140.

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

llvm-svn: 356510

Delete more dead code.

All of this is code that is unreferenced.  Removing as much of
this as possible makes it more easy to determine what functionality
is missing and/or shared between LLVM and LLDB's DWARF interfaces.

llvm-svn: 356509

Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib= [take 2]

"clang++ hello.cc --rtlib=compiler-rt"

now can works without specifying additional unwind or exception
handling libraries.

This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.

This should address the issues from the previous version.

Update tests for new --unwindlib semantics.

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

llvm-svn: 356508

Move options to separate checks that do not need to immediately follow the previous option. NFCI

llvm-svn: 356507

CodeGen: Refactor regallocator command line and target selection

This will allow targets more flexibility to replace the
register allocator core passes. In a future commit,
AMDGPU will run the core register assignment passes
twice, and will also want to disallow using the
standard -regalloc option.

llvm-svn: 356506

Revert "[libc++] Build <filesystem> support as part of the dylib"

When I applied r356500 (https://reviews.llvm.org/D59152), I somehow
deleted all of filesystem's tests. I will revert r356500 and re-apply
it properly.

llvm-svn: 356505

Fix char.traits.specializations.char8_t main return

llvm-svn: 356504

Fixup ABI lists on Linux after adding <filesystem> to the dylib.

llvm-svn: 356503

Add visibility attributes and inline to some vector methods.

Adding filesystem to the dylib caused some vector symbols to leak
into the set of exported symbols. This patch hides those symbols.

llvm-svn: 356502

RegAllocFast: Do not allocate registers for undef uses

Do not actually allocate a register for an undef use. Previously we we
would create unnecessary reload instruction for undef uses where the
register wasn't live.

Patch by Matthias Braun

llvm-svn: 356501

[libc++] Build <filesystem> support as part of the dylib

Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.

Reviewers: mclow.lists, EricWF, serge-sans-paille

Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits

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

llvm-svn: 356500

RegAllocFast: Remove early selection loop, the spill calculation will report cost 0 anyway for free regs

The 2nd loop calculates spill costs but reports free registers as cost
0 anyway, so there is little benefit from having a separate early
loop.

Surprisingly this is not NFC, as many register are marked regDisabled
so the first loop often picks up later registers unnecessarily instead
of the first one available in the allocation order...

Patch by Matthias Braun

llvm-svn: 356499

Fix for ABS legalization on PPC buildbot.

llvm-svn: 356498

Fix unused variable warning. NFCI.

llvm-svn: 356497

[OPENMP]Check that global vars require predefined allocator.

According to OpenMP, 2.11.3 allocate Directive, Restrictions, C / C++,
if a list item has a static storage type, the allocator expression in
  the allocator clause must be a constant expression that evaluates to
  one of the predefined memory allocator values. Added check for this
  restriction.

llvm-svn: 356496

Remove some dead DWARF enum -> string conversion functions.

llvm-svn: 356495

Allow unordered loads to be considered invariant in CodeGen

The actual code change is fairly straight forward, but exercising it isn't. First, it turned out we weren't adding the appropriate flags in SelectionDAG. Second, it turned out that we've got some optimization gaps, so obvious test cases don't work.

My first attempt (in atomic-unordered.ll) points out a deficiency in our peephole-opt folding logic which I plan to fix separately. Instead, I'm exercising this through MachineLICM.

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

llvm-svn: 356494

Fix fenv.pass.cpp signature for main

And make main return.

llvm-svn: 356493

Revert "[Remarks] Add a new Remark / RemarkParser abstraction"

This reverts commit 51dc6a8c84cd6a58562e320e1828a0158dbbf750.

Breaks
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/20034/steps/build%20stage%201/logs/stdio.

llvm-svn: 356492

[Remarks] Add a new Remark / RemarkParser abstraction

This adds a Remark class that allows us to share code when working with
remarks.

The C API has been updated to reflect this. Instead of the parser
generating C structs, it's now using a C++ object that is used through
opaque pointers in C. This gives us much more flexibility on what
changes we can make to the internal state of the object and interacts
much better with scenarios where the library is used through dlopen.

* C API updates:
  * move from C structs to opaque pointers and functions
  * the remark type is now an enum instead of a string
* unit tests updates:
  * use mostly the C++ API
  * keep one test for the C API
  * rename to YAMLRemarksParsingTest
* a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute.
* a new error message was added: "expected a remark tag."
* llvm-opt-report has been updated to use the C++ parser instead of the
C API

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

llvm-svn: 356491

Delete dead code.

Most of these are Dump functions that are never called, but there
is one instance of entire unused classes (DWARFDebugMacinfo and
DWARFDebugMacinfoEntry) which are also unreferenced in the codebase).

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

llvm-svn: 356490

[ValueTracking] Use computeConstantRange() for unsigned add/sub overflow

Improve computeOverflowForUnsignedAdd/Sub in ValueTracking by
intersecting the computeConstantRange() result into the ConstantRange
created from computeKnownBits(). This allows us to detect some
additional never/always overflows conditions that can't be determined
from known bits.

This revision also adds basic handling for constants to
computeConstantRange(). Non-splat vectors will be handled in a followup.

The signed case will also be handled in a followup, as it needs some
more groundwork.

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

llvm-svn: 356489

[libc++] Mark internal types of std::filesystem as hidden

Summary:
Otherwise, implicit instantiations of templates with these types can
cause the dylib to start exporting the vtable/RTTI of the instantiation.
Giving hidden visibility to those types causes the compiler to understand
that they are not used outside the dylib, and as a result implicitly
instantiated vtables/RTTI of templates with those internal types will
get hidden visibility.

Reviewers: EricWF

Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits

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

llvm-svn: 356488

[ScriptInterpreterPython] Remove dead code.

llvm-svn: 356487

[StackFrameRecognizer] Remove unneeded LLDB_DISABLE_PYTHON.

llvm-svn: 356486

gn build: Merge r356387.

llvm-svn: 356485

gn build: Merge r356451.

llvm-svn: 356484

[X86][SSE] SimplifyDemandedVectorEltsForTargetNode - handle repeated shift amounts

If a value with multiple uses is only ever used for SSE shift amounts then we know that only the bottom 64-bits are needed.

llvm-svn: 356483

[AtomicExpand] Fix a crash bug when lowering unordered loads to cmpxchg

Add tests for wider atomic loads and stores.  In the process, fix a crasher where we appearently handled unorder stores, but not loads, when lowering to cmpxchg idioms.

llvm-svn: 356482

[lldb] [Reproducer] Move SBRegistry registration into declaring files

Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability.  The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.

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

llvm-svn: 356481

[OPENMP]Remove unused parameter, NFC.

Parameter CodeGenModule &CGM is not required for CGOpenMPRuntime member
functions, since class holds the reference to the CGM.

llvm-svn: 356480

[OpenCL] Minor improvements in default header testing

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

llvm-svn: 356479

[MIPS][microMIPS] Enable dynamic stack realignment

Dynamic stack realignment was disabled on micromips by checking if
target has standard encoding. We simply change the condition to skip
Mips16 only.

Patch by Mirko Brkusanin.

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

llvm-svn: 356478

[NFC] Fix unused variable in release builds

This was introduced in rL356468.

llvm-svn: 356477

[DAGCombine] Fix a miscompile when reducing BUILD_VECTORs to a shuffle

In r311255 we added a case where we split vectors whose elements are
all derived from the same input vector so that we could shuffle it
more efficiently. In doing so, createBuildVecShuffle was taught to
adjust for the fact that all indices would be based off of the first
vector when this happens, but it's possible for the code that checked
that to fire incorrectly if we happen to have a BUILD_VECTOR of
extracts from subvectors and don't hit this new optimization.

Instead of trying to detect if we've split the vector by checking if
we have extracts from the same base vector, we can just pass that
information into createBuildVecShuffle, avoiding the miscompile.

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

llvm-svn: 356476

[Sema] Adjust addr space of reference operand in compound assignment

When we create overloads for the builtin compound assignment operators
we need to preserve address space for the reference operand taking it
from the argument that is passed in.

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

llvm-svn: 356475

Fix unused variable warning. NFCI.

llvm-svn: 356474