Noticed while looking for similar cases to rG931ec74f - SimplifyDemandedVectorElts and shuffle combining both should handle this now.

There are following issues with `CFIProgram::parse` code:

1) Invalid CFI opcodes were never tested. And currently a test would fail
when the `LLVM_ENABLE_ABI_BREAKING_CHECKS` is enabled. It happens because
the `DataExtractor::Cursor C` remains unchecked when the
"Invalid extended CFI opcode" error is reported:

```
.eh_frame section at offset 0x1128 address 0x0:
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
```

2) It is impossible to reach the "Invalid primary CFI opcode" error with the current code.
There are 3 possible primary opcode values and all of them are handled. Hence this error
should be replaced with llvm_unreachable.

3) Errors currently reported are upper-case.

This patch refines the code in the `CFIProgram::parse` method to fix all issues mentioned
and adds unit tests for all possible invalid extended CFI opcodes.

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

This is a follow-up for D83225. This does the following:
1) Adds missing tests for existent errors.
2) Stops using `unwrapOrError` to propagate errors to caller.
   (I am trying to get rid of all `unwrapOrErr` calls in the llvm-readelf code).
3) Improves error messages reported slightly.

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

In DAGTypeLegalizer::SplitVecRes_ExtendOp I have replaced an invalid
call to getVectorNumElements() with a call to getVectorMinNumElements(),
since the code path works for both fixed and scalable vectors.

This fixes up a warning in the following test:

  sve-sext-zext.ll

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

Calling getVectorNumElements() is not safe for scalable vectors and we
should normally use getVectorElementCount() instead. However, for the
code changed in this patch I decided to simply move the instantiation of
the variable 'OutNumElems' lower down to the place where only fixed-width
vectors are used, and hence it is safe to call getVectorNumElements().

Fixes up one warning in this test:

  sve-sext-zext.ll

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

For the GetElementPtr case in function
  AddressingModeMatcher::matchOperationAddr
I've changed the code to use the TypeSize class instead of relying
upon the implicit conversion to a uint64_t. As part of this we now
check for scalable types and if we encounter one just bail out for
now as the subsequent optimisations doesn't currently support them.

This changes fixes up all warnings in the following tests:

  llvm/test/CodeGen/AArch64/sve-ld1-addressing-mode-reg-imm.ll
  llvm/test/CodeGen/AArch64/sve-st1-addressing-mode-reg-imm.ll

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

This patch introduces 3 new direct conversions for SPIR-V ops:
- `spv.Select`
- `spv.Undef`
- `spv.FMul` that was skipped in the patch with arithmetic ops

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

`__stack_chk_fail` does not return, but `unreachable` was not generated
following `call __stack_chk_fail`. This had a possibility to generate an
invalid binary for functions with a return type, because
`__stack_chk_fail`'s return type is void and `call __stack_chk_fail` can
be the last instruction in the function whose return type is non-void.
Generating `unreachable` after it makes sure CFGStackify's
`fixEndsAtEndOfFunction` handles it correctly.

Reviewed By: tlively

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

This patch adds support for eliminating stores by free & lifetime.end
calls. We can remove stores that are not read before calling a memory
terminator and we can eliminate all stores after a memory terminator
until we see a new lifetime.start. The second case seems to not really
trigger much in practice though.

Reviewers: dmgreen, rnk, efriedma, bryant, asbirlea, Tyker

Reviewed By: asbirlea

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

Summary: Add support for warning incase of default constructed unique pointer dereferences

Reviewed By: NoQ, Szelethus, vsavchenko, xazax.hun

Tags: #clang

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

optimizeMemoryInst was reporting no change while still modifying the IR.
Inspect the status of TypePromotionTransaction to get a better status.

Related to https://reviews.llvm.org/D80916

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

It seems that these were inserted here inadvertently instead of using
standard `return`.

Revert "[X86] Add back the assert in getImpliedFeatures that I removed in ef4cc70f"

This reverts commit 91f70675.
It seems to break most (all?) hwasan tests.

Summary:
These two tests are flaky on lldb Arm buildbot as well. They are already
being skipped for aarch64. I am going to mark them skipped for Arm.

Tags: #lldb

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

These represent the same thing but 64BIT only showed up from
getHostCPUFeatures providing a list of featuers to clang. While
EM64T showed up from getting the features for a named CPU.

EM64T didn't have a string specifically so it would not be passed
up to clang when getting features for a named CPU. While 64bit
needed a name since that's how it is index.

Merge them by filtering 64bit out before sending features to clang
for named CPUs.

For an addition with an immediate in specific ranges, a pair of
addi-addi can be generated instead of the ordinary lui-addi-add serial.

Reviewed By: MaskRay, luismarques

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

... to shift/add or shift/sub.

Do not enable it on riscv32 with the M extension where decomposeMulByConstant
may not be an optimization.

Reviewed By: luismarques, MaskRay

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

Add MatrixTimesMatrix operation to SPIRV Dialect and add NoSideEffect trait
to Matrix ops.

Reviewed By: antiagainst

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

sequence on a glvalue expression.

If the sequence is supposed to perform an lvalue-to-rvalue conversion,
then one will be specified as the first conversion in the sequence.
Otherwise, one should not be invented.

- This will eliminate the need to pass an empty `ArrayRef<NamedAttribute>{}` when
  no named attributes are required on the function.

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

An accidental change snuck in here

This reverts commit f1d290d8.

These represent the same thing but 64BIT only showed up from
getHostCPUFeatures providing a list of featuers to clang. While
EM64T showed up from getting the features for a named CPU.

EM64T didn't have a string specifically so it would not be passed
up to clang when getting features for a named CPU. While 64bit
needed a name since that's how it is index.

Merge them by filtering 64bit out before sending features to clang
for named CPUs.

This code should reside in the c-library.

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

This fixes https://bugs.llvm.org/show_bug.cgi?id=46605.

rdar://problem/65158878

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

Create the framework and testing environment for MLIR Reduce - a tool
with the objective to reduce large test cases into smaller ones while
preserving their interesting behavior.

Implement the functionality to parse command line arguments, parse the
MLIR test cases into modules and run the interestingness tests on
the modules.

Reviewed By: jpienaar

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

Do not rewrite LEN(x) or x%len to the expression that specifies
the length of x when that length is not a constant expression.
Its value may have changed since the value of the expression was
first captured in the definition of the object.

Reviewed By: tskeith, sscalpone

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

`ObjCRuntime` and `CommentOpts.BlockCommandNames` are checked by
`ASTReader::checkLanguageOptions`, but are not part of the module
context hash. This can lead to errors when using implicit modules if
different TUs have different values for these options when using the
same module cache.

This was not hit very often due to the rare usage of
`-fblock-command-names=` and that `ObjCRuntime` is by default set by
the target triple, which is part of the existing context hash.

Commit 95a28df5 provided implementation for GOMP*_nonmonotonic*runtime*
functions. Now the tests succeed with gcc 9 and 10

[X86] Add back the assert in getImpliedFeatures that I removed in ef4cc70f

I've added additional features to the table so I want to see if
the bots are happier with this.

This seems to break http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/24371

This reverts commit eb46137d.

*.yaml tests don't currently run, so we failed to notice it.

Suggested by Vedant.

This gets rid of some surprising interplay between the flags.
Mainly needed because of Rosetta debugserver & Apple Silicon.

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