Alive2: https://alive2.llvm.org/ce/z/FzcrpH

It should fix following error:

  Undefined symbols for architecture x86_64:
    "llvm::outs()", referenced from:
        FindNamedClassVisitor::VisitCXXRecordDecl(clang::CXXRecordDecl*) in FindClassDecls.cpp.o

In clangd-12 the ability to override what clang tidy checks should run was moved into config.
For the 13 release its a wise progression to remove the command line option for this.

Reviewed By: sammccall

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

The normalization of matchers means that this now works in all language
modes.

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

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

Alive2: https://alive2.llvm.org/ce/z/4nkNGh

As discussed on D96413, as long as the promoted bits of the args are zero we can use the basic ISD::USUBSAT pattern directly, without the shifting like we do for other ops.

I think something similar should be possible for ISD::UADDSAT as well, which I'll look at later.

Also, create a ISD::USUBSAT node directly - this will be expanded back by the legalizer later on if necessary.

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

Instcombine will convert the nonnull and alignment assumption that use the boolean condtion
to an assumption that uses the operand bundles when knowledge retention is enabled.

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

We lost this in D56387/rG69bc0990 - where I got the src/dst bitwidths mixed up and assumed getValidShiftAmountConstant would catch it.

Patch by @craig.topper - confirmed by @Carrot that it fixes PR49162

Previously we assumed `rethrow`'s argument was always 0, but it turned
out `rethrow` follows the same rule with `br` or `delegate`:
https://github.com/WebAssembly/exception-handling/pull/137
https://github.com/WebAssembly/exception-handling/issues/146#issuecomment-777349038

Currently `rethrow`s generated by our backend always rethrow the
exception caught by the innermost enclosing catch, so this adds a
function to compute that and replaces `rethrow`'s argument with its
computed result.

This also renames `EHPadStack` in `InstPrinter` to `TryStack`, because
in CFGStackify we use `EHPadStack` to mean the range between
`catch`~`end`, while in `InstPrinter` we used it to mean the range
between `try`~`catch`, so choosing different names would look clearer.
Doesn't contain any functional changes in `InstPrinter`.

Reviewed By: dschuff

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

When newer build has duplicate issues the script tried to
remove it from the list more than once.  The new approach
changes the way we filter out matching issues.

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

Reviewed By: ldionne, compnerd

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

DetectionContext objects are stored as values in a DenseMap. When the
DenseMap reaches its maximum load factor, it is resized and all its
objects moved to a new memory allocation. Unfortunately Scop object have
a reference to its DetectionContext. When the DenseMap resizes, all the
DetectionContexts reference now point to invalid memory, even if caused
by an unrelated DetectionContext.

Even worse, NewPM's ScopPassManager called isMaxRegionInScop with the
Verify=true parameter before each pass. This caused the old
DetectionContext to be removed an a new on created and re-verified.
Of course, the Scop object was already created pointing to the old
DetectionContext. Because the new DetectionContext would
usually be stored at the same position in the DenseMap, the reference
would usually reference the new DetectionContext of the same Region.
Usually.
If not, the old position still points to memory in the DenseMap
allocation (unless also a resizing occurs) such that tools like Valgrind
and AddressSanitizer would not be able to diagnose this.

Instead of storing the DetectionContext inside the DenseMap, use a
std::unique_ptr to a DetectionContext allocation, i.e. it will not move
around anymore. This also allows use to remove the very strange

    DetectionContext(const DetectionContext &&)

copy/move(?) constructor. DetectionContext objects now are neither
copied nor moved.

As a result, every re-verification of a DetectionContext will use a new
allocation. Therefore, once a Scop object has been created using a
DetectionContext, it must not be re-verified (the Scop data structure
requires its underlying Region to not change before code generation
anyway). The NewPM may call isMaxRegionInScop only with
Validate=false parameter.

Identified with readability-const-return-type.

Perform DSOLocal propagation within summary list of every GV. This
avoids the repeated query of this information during function
importing.

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

In the past, it was stated in D87994 that it is allowed to dereference a pointer that is partially undefined
if all of its possible representations fit into a dereferenceable range.
The motivation of the direction was to make a range analysis helpful for assuring dereferenceability.
Even if a range analysis concludes that its offset is within bounds, the offset could still be partially undefined; to utilize the range analysis, this relaxation was necessary.
https://groups.google.com/g/llvm-dev/c/2Qk4fOHUoAE/m/KcvYMEgOAgAJ has more context about this.

However, this is currently blocking another optimization, which is annotating the noundef attribute for library functions' arguments. D95122 is the patch.
Currently, there are quite a few library functions which cannot have noundef attached to its pointer argument because it can be transformed from load/store.
For example, MemCpyOpt can convert stores into memset:

```
store p, i32 0
store (p+1), i32 0 // Since currently it is allowed for store to have partially undefined pointer..
->
memset(p, 0, 8)    // memset cannot guarantee that its ptr argument is noundef.
```

A bigger problem is that this makes unclear which library functions are allowed to have 'noundef' and which functions aren't (e.g., strlen).
This makes annotating noundef almost impossible for this kind of functions.

This patch proposes that all memory operations should have well-defined pointers.
For memset/memcpy, it is semantically equivalent to running a loop until the size is met (and branching on undef is UB), so the size is also updated to be well-defined.

Strictly speaking, this again violates the implication of dereferenceability from range analysis result.
However, I think this is okay for the following reasons:

1. It seems the existing analyses in the LLVM main repo does not have conflicting implementation with the new proposal.
`isDereferenceableAndAlignedPointer` works only when the GEP offset is constant, and `isDereferenceableAndAlignedInLoop` is also fine.

2. A possible miscompilation happens only when the source has a pointer with a *partially* undefined offset (it's okay with poison because there is no 'partially poison' value).
But, at least I'm not aware of a language using LLVM as backend that has a well-defined program while allowing partially undefined pointers.
There might be such a language that I'm not aware of, but improving the performance of the mainstream languages like C and Rust is more important IMHO.

Reviewed By: jdoerfert

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

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

This reverts commit df1eeaa7.

Buildbot failure.

This patch is a follow up of D96422 and move ComplexType to TableGen.

Reviewed By: schweitz, mehdi_amini

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

This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.

Reviewed By: schweitz, mehdi_amini

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

As of binutils 2.36, GNU strip calls chown(2) for "sudo strip foo" and
"sudo strip foo -o foo", but no "sudo strip foo -o bar" or "sudo strip
foo -o ./foo". In other words, while "sudo strip foo -o bar" creates a
new file bar with root access, "sudo strip foo" will keep the owner and
group of foo unchanged. Currently llvm-objcopy and llvm-strip behave
differently, always changing the owner and gropu to root. The
discrepancy prevents Chrome OS from migrating to llvm-objcopy and
llvm-strip as they change file ownership and cause intended users/groups
to lose access when invoked by sudo with the following sequence
(recommended in man page of GNU strip).

1.<Link the executable as normal.>
1.<Copy "foo" to "foo.full">
1.<Run "strip --strip-debug foo">
1.<Run "objcopy --add-gnu-debuglink=foo.full foo">

This patch makes llvm-objcopy and llvm-strip follow GNU's behavior.

Link: crbug.com/1108880

Reviewed By: bader, eandrews

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

This patch hides the logic for setting the location kind of an entry
value inside the begin/finalize/cancel functions. This way we get rid
the strange workaround that is currently in setLocation().

In the future, this will allow us to set the location kind of the
entry value independently from the location kind of the main
expression.

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

It appears some instructions doesn't have the debug location info and the symbolizer will return an empty call stack for them which will cause some crash later in profile unwinding. Actually we do not record the sample info for them, so this change just filter out those instruction.

As those instruction would appears at the begin and end of the instruction list, without them we need to add the boundary check for IP `advance` and `backward`.

Also for pseudo probe based profile, we actually don't need the symbolized location info, so here just change to use an empty stack for it. This could save half of the binary loading time.

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

I've already witnessed two separate changes missing runNewPMPasses()
because runNewPMCustomPasses() is so similar.

This cleans up some duplicated code.

Reviewed By: tejohnson

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

vec_xl() and vec_xst() should not emit alignment hints since they take a
scalar pointer and also add a byte offset if passed.

This patch uses memcpy to achieve the desired result.

Review: Ulrich Weigand

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

Swift async functions receive function arguments inside a
heap-allocated data structure, similar to how ObjC block captures or
C++ coroutine arguments are implement. In DWARF they are described
relative to an entry value that produces a pointer into that heap
object. At typical location looks like

DW_OP_entry_value [ DW_OP_reg14 ] DW_OP_deref DW_OP_plus_uconst 32 DW_OP_deref

This allows the unwinder (which has special ABI knowledge to restore
the contents of r14) to push the base address onto the stack thus
allowing the deref/offset operations to continue. The result of the
entry value is a scalar, because DW_OP_reg14 is a register location —
as it should be since we want to restore the pointer value contained
in r14 at the beginning of the function and not the historical memory
contents it was pointing to. The entry value should restore the
address, which is still valid, not the contents at function entry.

To make this work, we need to allow LLDB to dereference Scalar stack
results like load addresses, which is what this patch
does. Unfortunately it is difficult to test this in isolation, since
the DWARFExpression unit test doesn't have a process.

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

The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537

[RISCV] Move riscv_vfmv_v_f_vl patterns to RISCVInstrInfoVVLPatterns.td for consistency with riscv_vmv_v_x_vl. NFC