This reverts commit d41f6cff.

The commit contained wrong phabricator link.

Reported by Static Analyzer Tool, Coverity:

Inside "SemaDeclCXX.cpp" file, in clang::Sema::CheckExplicitlyDefaultedSpecialMember(clang::CXXMethodDecl *, clang::Sema::CXXSpecialMember, clang::SourceLocation): Return value of function which returns null is dereferenced without checking.

  //returned_null: getAs returns nullptr (checked 117 out of 143 times).
  // var_assigned: Assigning: Type = nullptr return value from getAs.
  const FunctionProtoType *Type = MD->getType()->getAs<FunctionProtoType>();

  //Dereference null return value (NULL_RETURNS)
  //dereference: Dereferencing a pointer that might be nullptr Type when calling getReturnType.
  ReturnType = Type->getReturnType();

  //Dereference null return value (NULL_RETURNS)
  //dereference: Dereferencing a pointer that might be nullptr Type when calling getParamType.
  QualType ArgType = ExpectedParams ? Type->getParamType(0) : QualType();

This patch uses castAs instead of getAs which will assert if the type doesn't match.

Reviewed By: erichkeane

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

This fixes a -Wunused-member-function warning, at the moment
`PyRegionIterator` is never constructed by anything (the only use was
removed in D111697), and iterating over region lists is just falling
back to a generic python iterator object.

Reviewed By: stellaraccident

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

This patch adds nosantize metadata to memory access instructions inserted by gcov emitProfileNotes(), making sanitizers skip these instructions when gcov and sanitizer are used together.

Reviewed By: nickdesaulniers

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

Currently blocks are always created with UnknownLoc's for their arguments. This
adds an `arg_locs` argument to all block creation APIs, which takes an optional
sequence of locations to use, one per block argument. If no locations are
supplied, the current Location context is used.

Reviewed By: ftynse

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

Reviewed By: thurston

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

If the input vector sizes are as same as tensor.pad result shape, the
masking is not needed. Otherwise, the masking is needed and the masking
operands should be as same as tensor.empty op.

Reviewed By: dcaballe

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

__sanitizer_get_current_allocated_bytes had as body, but allocator
caches were not registered to collect stats. It's done by
SizeClassAllocator64LocalCache::Init().

Reviewed By: thurston

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

Test was printing same result twice

Reviewed By: K-Wu

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

Since the tosa-to-linalg conversion does not support the quant dialect type, we can treat it as unsupported instead of crash.  Issue was reported https://github.com/llvm/llvm-project/issues/62367

Reviewed By: springerm

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

[RISCV] Add a special caes to performVFMADD_VLCombine to support the multiplicand being the same value.

The one use check will fail if there are two uses in the same
instruction. Add a special case for this.

Currently, the header file contains all the undefs, followed by all the
define X 0. This will be inconvenient for re-enabling interceptors,
because we would need to comment out (or delete) the corresponding macros
in two different places.

This patch groups together the macros for each function.

Additionally, it adds the suggestion that interceptors should be
re-enabled by commenting out (not deleting) the macros.

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

Msan reports https://reviews.llvm.org/P8308
The reason is if PointerIntPair is not properly
constructed, setPointer uses Info::updatePointer
on uninitialized value.

Reviewed By: #clang, rsmith

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

"LinkageAttributes" decoration allow a SPIR-V module to import
external functions and global variables, or export functions or
global variables for other SPIR-V modules to link against and use.

Import/export capability is extremely important when using outside
libraries (e.g., intrinsic libraries).

Added decorations:
- LinkageAttributes

Reviewed By: antiagainst

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

The patterns are for a vpmerge with an all 1s mask, but we are
able to handle that with a post-isel peephole recently.

This change just turns the unhandled BOZ fatal error into TODO
like in non-HLFIR path.

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

This allow to have no InitLinkerInitialized and let AllocatorGlobalStats
accept registration before allocator initialization.

ShapedType is a virtual type rather than a concrete one.
We don't have an implmentation for this API too.

Reviewed By: makslevental

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

  Aligns the shift requirement with the TOSA specification.

Reviewed By: eric-k256

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

This is just to test that the PSTL works with parallelization. This is not supposed to be a production-ready backend.

Reviewed By: ldionne, #libc

Spies: EricWF, arichardson, libcxx-commits

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

The MathToSPIRV conversion pass missed out a pattern for converting
math::AbsIOP to spirv::CLSAbsOp

Reviewed By: antiagainst

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

This refactors and exposes EqualizeRanks utility function
from within TosaMakeBroadcastable pass so it may be used to
reshape operator inputs to equal ranks.

Signed-off-by: Tai Ly <tai.ly@arm.com>

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

This revision is a part of a series of patches extending AddressSanitizer C++ container overflow detection capabilities by adding annotations, similar to those existing in std::vector, to std::string and `std::deque` collections. These changes allow ASan to detect cases when the instrumented program accesses memory which is internally allocated by the collection but is still not in-use (accesses before or after the stored elements for `std::deque`, or between the size and capacity bounds for `std::string`).

The motivation for the research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a std::equals function that took `iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom comparison function). When object `iter1` was longer than `iter2`, read out-of-bounds on `iter2` could happen. Container sanitization would detect it.

This revision introduces annotations for `std::deque`. Each chunk of the container can now be annotated using the `__sanitizer_annotate_double_ended_contiguous_container` function, which was added in the rG1c5ad6d2. Any attempt to access poisoned memory will trigger an ASan error. Although false negatives are rare, they are possible due to limitations in the ASan API, where a few (usually up to 7) bytes before the container may remain unpoisoned. There are no false positives in the same way as with `std::vector` annotations.

This patch only supports objects (deques) that use the standard allocator. However, it can be easily extended to support all allocators, as suggested in the D146815 revision.

Furthermore, the patch includes the addition of the `is_double_ended_contiguous_container_asan_correct` function to libcxx/test/support/asan_testing.h. This function can be used to verify whether a `std::deque` object has been correctly annotated.

Finally, the patch extends the unit tests to verify ASan annotations (added LIBCPP_ASSERTs).
If a program is compiled without ASan, all helper functions will be no-ops. In binaries with ASan, there is a negligible performance impact since the code from the change is only executed when the deque container changes in size and it’s proportional to the change. It is important to note that regardless of whether or not these changes are in use, every access to the container's memory is instrumented.

Reviewed By: #libc, philnik

Spies: vitalybuka, hans, mikhail.ramalho, Enna1, #sanitizers, philnik, libcxx-commits

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

Now that operands have moved to the new data operands lowering, this
function is not used anymore.

Reviewed By: vzakhari

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

Most transforms should now be performed on llvm.is.fpclass. Unlike the
generic intrinsic, this supports variable test masks.

The move of the bytecode serialization to be tablegen driven in
https://reviews.llvm.org/D144820 added a new condition in the reading
path that forbid 0-sized integer, even though we still produce them.

Fix #62920

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

[libc++, std::vector] call the optimized version of __uninitialized_allocator_copy for trivial types

See: https://github.com/llvm/llvm-project/issues/61987

Fix suggested by: @philnik and @var-const

Reviewers: philnik, ldionne, EricWF, var-const

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

Testing:
ninja check-cxx check-clang check-llvm

Benchmark Testcases (BM_CopyConstruct, and BM_Assignment) added.

performance improvement:

Run on (8 X 4800 MHz CPU s)
CPU Caches:
  L1 Data 48 KiB (x4)
  L1 Instruction 32 KiB (x4)
  L2 Unified 1280 KiB (x4)
  L3 Unified 12288 KiB (x1)
Load Average: 1.66, 3.02, 2.43

Comparing build-runtimes-base/libcxx/benchmarks/vector_operations.libcxx.out to build-runtimes/libcxx/benchmarks/vector_operations.libcxx.out
Benchmark                                                   Time             CPU      Time Old      Time New       CPU Old       CPU New
----------------------------------------------------------------------------------------------------------------------------------------
BM_ConstructSize/vector_byte/5140480                     +0.0362         +0.0362        116906        121132        116902        121131
BM_CopyConstruct/vector_int/5140480                      -0.4563         -0.4577       1755224        954241       1755330        951987
BM_Assignment/vector_int/5140480                         -0.0222         -0.0220        990045        968095        989917        968125
BM_ConstructSizeValue/vector_byte/5140480                +0.0308         +0.0307        116970        120567        116977        120573
BM_ConstructIterIter/vector_char/1024                    -0.0831         -0.0831            19            17            19            17
BM_ConstructIterIter/vector_size_t/1024                  +0.0129         +0.0131            88            89            88            89
BM_ConstructIterIter/vector_string/1024                  -0.0064         -0.0018         54455         54109         54208         54112
OVERALL_GEOMEAN                                          -0.0845         -0.0842             0             0             0             0

FYI, the perf improvements for BM_CopyConstruct due to this patch is mostly subsumed by the https://reviews.llvm.org/D149826. However this patch still adds value by converting copy to memmove (the second testcase).

Before the patch:

```
define linkonce_odr dso_local void @_ZNSt3__16vectorIiNS_9allocatorIiEEE18__construct_at_endIPiS5_EEvT_T0_m(ptr noundef nonnull align 8 dereferenceable(24) %0, ptr noundef %1, ptr noundef %2, i64 noundef %3) local_unnamed_addr #4 comdat align 2 {
  %5 = getelementptr inbounds %"class.std::__1::vector", ptr %0, i64 0, i32 1
  %6 = load ptr, ptr %5, align 8, !tbaa !12
  %7 = icmp eq ptr %1, %2
  br i1 %7, label %16, label %8

8:                                                ; preds = %4, %8
  %9 = phi ptr [ %13, %8 ], [ %1, %4 ]
  %10 = phi ptr [ %14, %8 ], [ %6, %4 ]
  %11 = icmp ne ptr %10, null
  tail call void @llvm.assume(i1 %11)
  %12 = load i32, ptr %9, align 4, !tbaa !14
  store i32 %12, ptr %10, align 4, !tbaa !14
  %13 = getelementptr inbounds i32, ptr %9, i64 1
  %14 = getelementptr inbounds i32, ptr %10, i64 1
  %15 = icmp eq ptr %13, %2
  br i1 %15, label %16, label %8, !llvm.loop !16

16:                                               ; preds = %8, %4
  %17 = phi ptr [ %6, %4 ], [ %14, %8 ]
  store ptr %17, ptr %5, align 8, !tbaa !12
  ret void
}
```

After the patch:
```
define linkonce_odr dso_local void @_ZNSt3__16vectorIiNS_9allocatorIiEEE18__construct_at_endIPiS5_EEvT_T0_m(ptr noundef nonnull align 8 dereferenceable(24) %0, ptr noundef %1, ptr noundef %2, i64 noundef %3) local_unnamed_addr #4 comdat align 2 {
  %5 = getelementptr inbounds %"class.std::__1::vector", ptr %0, i64 0, i32 1
  %6 = load ptr, ptr %5, align 8, !tbaa !12
  %7 = ptrtoint ptr %2 to i64
  %8 = ptrtoint ptr %1 to i64
  %9 = sub i64 %7, %8
  %10 = ashr exact i64 %9, 2
  tail call void @llvm.memmove.p0.p0.i64(ptr align 4 %6, ptr align 4 %1, i64 %9, i1 false)
  %11 = getelementptr inbounds i32, ptr %6, i64 %10
  store ptr %11, ptr %5, align 8, !tbaa !12
  ret void
}
```

This is due to the optimized version of uninitialized_allocator_copy function.

__sanitizer_get_current_allocated_bytes had as body, but allocator
caches were not registered to collect stats. It's done by
SizeClassAllocator64LocalCache::Init().

Reviewed By: thurston

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

This patch modifies the description in TosaOps.td, taking into account
all the arguments, and supplying examples.

Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>

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

https://reviews.llvm.org/D151104 moved PDL-related transform ops into an extension and updated the Bazel build, but one tiny thing fell through the cracks - TransformOpsPyFiles also needs to include the newly introduced `mlir/python/mlir/dialects/_transform_pdl_extension_ops_ext.py`.

Reviewed By: saugustine, bkramer

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

Reviewed By: MaskRay

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

This is a very simple test that calls wsclen. There are currently no other HWASan tests that call wsclen, which is why the wcslen interceptor issue (triggered by https://reviews.llvm.org/D150708 and fixed in https://reviews.llvm.org/D150909) was only detected by stage2/hwasan check on the buildbots. With this test, the issue would have been caught by stage1 check-sanitizer, with a more obvious diagnosis.

Reviewed By: vitalybuka

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