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

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

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

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

llvm-svn: 356568

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

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

llvm-svn: 356567

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

[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

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

llvm-svn: 356563

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

llvm-svn: 356560

llvm-svn: 356559

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

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

llvm-svn: 356557

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

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

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

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

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

llvm-svn: 356552

llvm-svn: 356551

Summary: Fixes 41150.

Reviewers: gchatelet

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

Tags: #llvm

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

llvm-svn: 356550

llvm-svn: 356549

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

llvm-svn: 356548

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

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

llvm-svn: 356543

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

Reviewers: ilya-biryukov

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

Tags: #clang

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

llvm-svn: 356541

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

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

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

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

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

llvm-svn: 356534

This reverts commit 6080a6fb (r356532).

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

llvm-svn: 356533

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

llvm-svn: 356532

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

llvm-svn: 356531

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

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