Changes from Git (git http://labmaster3.local/git/llvm-project.git)


  1. [IR] NoFree IntrinsicProperty. (details)
  2. [lldb] Modernize asserts (details)
  3. [Alignment][NFC] Migrate AtomicExpandPass to Align (details)
  4. [AST][RecoveryExpr] Add error-bit to NestNameSpecifierDependence and TemplateNameDependence. (details)
  5. [mlir] Extended BufferPlacement to support nested region control flow. (details)
  6. [clangd] Remove redundant `findRefs` calls. NFC. (details)
  7. [llvm][Z3][NFC] Improve mkBitvector performance (details)
  8. [SystemZ] Add NoMerge MIFlag (details)
  9. [lldb][NFC] Remove ImportInProgress lock in ClangASTSource (details)
Commit aa93d84db93451488fc9c645fb970b8f7e481292 by sstipanovic
[IR] NoFree IntrinsicProperty.

Separate introduction of IntrNoFree property as suggested in D70365

Reviewers: arsenm, nhaehnle

Tags: #llvm

Differential Revision:
The file was modifiedllvm/utils/TableGen/CodeGenTarget.cpp
The file was modifiedllvm/utils/TableGen/CodeGenIntrinsics.h
The file was modifiedllvm/include/llvm/IR/
The file was modifiedllvm/utils/TableGen/IntrinsicEmitter.cpp
Commit 621f84567920bf5a8d79789f01a622115ec8252d by Raphael Isemann
[lldb] Modernize asserts
The file was modifiedlldb/test/API/lang/cpp/operator-overload/
Commit 2c5ff48e61b5611dee5696c103e654c98d7e43f1 by gchatelet
[Alignment][NFC] Migrate AtomicExpandPass to Align

This is a followup on D78403.
I'm unsure about `getAtomicOpAlign` overloads that take `AtomicRMWInst` and `AtomicCmpXchgInst`, shouldn't `getAlign` provide the correct answer already?

Differential Revision:
The file was modifiedllvm/include/llvm/IR/Instructions.h
The file was modifiedllvm/lib/IR/Instructions.cpp
The file was modifiedllvm/lib/CodeGen/AtomicExpandPass.cpp
Commit d28267f9810ce8642b27279b91a3a195ba932ce2 by hokein.wu
[AST][RecoveryExpr] Add error-bit to NestNameSpecifierDependence and TemplateNameDependence.

We might lose the error-bit if the error-bit goes through the code path
"error type/expr" -> "error template argument" -> "nested name specifier" ->
... -> "template Specialization type"

Template name also needs this, as a template can be nested into
an error specifier, e.g. templateName apply in
`TC<decltype(<recovery-expr>(Foo, int()))>::template apply`

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision:
The file was modifiedclang/include/clang/AST/DependenceFlags.h
The file was modifiedclang/test/Sema/
Commit 6f5da84f7bb31c7c2fcb78e64d5dc3baea1c60f2 by herhut
[mlir] Extended BufferPlacement to support nested region control flow.

Summary: The current BufferPlacement implementation does not support
nested region control flow. This CL adds support for nested regions via
the RegionBranchOpInterface and the detection of branch-like
(ReturnLike) terminators inside nested regions.

Differential Revision:
The file was modifiedmlir/lib/Transforms/BufferPlacement.cpp
The file was modifiedmlir/test/lib/Dialect/Test/TestDialect.cpp
The file was modifiedmlir/test/lib/Dialect/Test/
The file was modifiedmlir/test/Transforms/buffer-placement.mlir
Commit 84ced55d9b7bade7c9db39f3bcebc6af333dc325 by 1585086582
[clangd] Remove redundant `findRefs` calls. NFC.

Remove redundant `findRefs` calls.

Reviewers: sammccall, kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

Differential Revision:
The file was modifiedclang-tools-extra/clangd/XRefs.cpp
Commit 815a8100e02966043a41ae6b366f23feb470e736 by benicsbalazs
[llvm][Z3][NFC] Improve mkBitvector performance

We convert `APSInt`s to Z3 Bitvectors in an inefficient way for most cases.
We should not serialize to std::string just to pass an int64 integer.

For the vast majority of cases, we use at most 64-bit width integers (at least
in the Clang Static Analyzer). We should simply call the `Z3_mk_unsigned_int64`
and `Z3_mk_int64` instead of the `Z3_mk_numeral` as stated in the Z3 docs.
Which says:
> It (`Z3_mk_unsigned_int64`, etc.) is slightly faster than `Z3_mk_numeral` since
> it is not necessary to parse a string.

If the `APSInt` is wider than 64 bits, we will use the `Z3_mk_numeral` with a
`SmallString` instead of a heap-allocated `std::string`.

Differential Revision:
The file was modifiedllvm/lib/Support/Z3Solver.cpp
Commit 6764869548a23d03b10b0a9af7aeac534959af29 by iii
[SystemZ] Add NoMerge MIFlag

This fixes ASan and MSan tests on SystemZ after
commit 6a822e20ce70 ("[ASan][MSan] Remove EmptyAsm and set the CallInst
to nomerge to avoid from merging.").

Based on commit 80e107ccd088 ("Add NoMerge MIFlag to avoid MIR branch

Reviewers: uweigand, jonpa

Reviewed By: uweigand

Subscribers: hiraditya, llvm-commits, Andreas-Krebbel

Tags: #llvm

Differential Revision:
The file was addedllvm/test/CodeGen/SystemZ/nomerge.ll
The file was modifiedllvm/lib/Target/SystemZ/SystemZISelLowering.cpp
Commit 502773d743417a7896e184b4000bcf20fddb7ad9 by Raphael Isemann
[lldb][NFC] Remove ImportInProgress lock in ClangASTSource


The ClangASTSource has a lock that globally disables all lookups into the
external AST source when we explicitly "guarded" copy a type. It's not used for
anything else, so importing declarations or importing types that are
dependencies of a declaration actually won't activate that lock. The lookups it
is supposed to prevent also don't actually happen in our test suite. The check
in `ClangExpressionDeclMap::FindExternalVisibleDecls` is never executed and the
check in the `ClangASTSource::FindExternalVisibleDeclsByName` is only ever
reached by the `Import-std-module` tests (which explicitly do a lookup into the
expression context on purpose).

This lock was added in 6abfabff6158076eccdf6fcac5a12894039de2c9 as a replacement
for a list of types we already looked up which appeared to be an optimisation
strategy. I assume back then this lock had a purpose but these days the
ASTImporter and LLDB seem to be smart enough to avoid whatever lookups this
tried to prevent.

I would say we remove it from LLDB. The main reason is that it blocks D81561
(which explicitly does a specific lookup to resolve placeholder types produced
by `-flimit-debug-info`) but it's semantics are also very confusing. The naming
implies it's a flag to indicate when we import something at the moment which is
practically never true as described above. Also the fact that it makes our
ExternalASTSource alternate between doing lookups into the debug info and
pretending it doesn't know any external decls could really break our lookup in
some weird way if Clang decides to cache a fake empty lookup result that was
generated while the lock was active.

Reviewers: labath, shafik, JDevlieghere, aprantl

Reviewed By: labath, JDevlieghere, aprantl

Subscribers: aprantl, abidh

Differential Revision:
The file was modifiedlldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
The file was modifiedlldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
The file was modifiedlldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h