We don't need an external script to scan all opcodes anymore, just use
`-opcode-index=-1`.

Looks like the reason they were disabled is the same as for Android
and it's fixed by 776a15d8

The types of SEH aren't x86(-32) vs x64 but rather stack-based exception chaining
vs table-based exception handling. x86-32 is the only arch for which Windows
uses the former. 32-bit ARM would use what is called Win64SEH today, which
is a bit confusing so instead let's just rename it to be a bit more clear.

Reviewed By: compnerd, rnk

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

We can sharpen the range of a AddRec if we know that it does not
self-wrap and know the symbolic iteration count in the loop. If we can
evaluate the value of AddRec on the last iteration and prove that at least
one its intermediate value lies between start and end, then no-wrap flag
allows us to conclude that all of them also lie between start and end. So
the estimate of range can be improved to union of ranges of start and end.

Switched off by default, can be turned on by flag.

Differential Revision: https://reviews.llvm.org/D89381
Reviewed By: lebedev.ri, nikic

CUDA buildbots complained about a redefinition when I landed D89971.
This is odd and I fail to understand where in the CUDA headers the other
definition is supposed to be. For now, given that CUDA doesn't need the
overload (AFAIKT), we simply restrict it to the OpenMP mode.

I just removed thread-prob-{1,2}.ll in
b2f05fae, so I am removing
thread-prob-3.ll to thread-prob-1.ll.

This patch removes extraneous calls to setEdgeProbability introduced
in c9148776.

The follow-up patch, a7b662d0, has
since fixed BranchProbabilityInfo::eraseBlock, so we don't need to
worry about getting stale values from getEdgeProbability.

Also, since getEdgeProbability(BB, BB->getSingleSuccessor()) returns
edge probability 1/1 by default for BB with exactly one successor
edge, we don't need to explicitly call setEdgeProbability.

This patch introduces almost no functional change, but we do end up
reducing debug messages from setEdgeProbability.

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

This reverts commit 5b3bf8b4.

This caused a regression in the ASan buildbot. See comments at
https://reviews.llvm.org/D89817 for more information.

This reverts commit a6336eab.

This commit broke check-llvm under ASan:

See http://lab.llvm.org:8011/#/builders/5/builds/446 for more details.

For any newly added parse function, clang-tidy complains. New parse
functions are implicitly defined by a macro "Parse##CLASS(N, IsDistinct)".
Now this macro and exising function definitions are corrected (lower case
first character). Some other variable/function names are also corrected
to comply LLVM coding style.

Reviewed By: djtodoro

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

SIPreAllocateWWMRegs was being inserted after RegisterCoalescer
but this pass does not exist during FastAlloc so pre-allocation
pass was never being run.
Insert pre-allocation after TwoAddressInstructionPass instead.

Reviewed By: rampitec

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

This matches the new PM model.

This will simplify debugging and tracking down problems.

Before we used to only mark unreachable static functions as dead if all
uses were known dead. Now we optimistically assume uses to be dead until
proven otherwise.

If we are looking at a call site argument it might be a load or call
which is in a different context than the call site argument. We cannot
simply use the call site argument range for the call or load.

Bug reported and reduced by Whitney Tsang <whitneyt@ca.ibm.com>.

The call is not free, unsure if  this is needed but it does not make it
worse either.

In the AANoAlias logic we determine if a pointer may have been captured
before a call. We need to look at other uses in the call not uses of the
call.

The new code is not perfect as it does not allow trivial cases where the
call has multiple arguments but it is at least not unsound and a TODO
was added.

Enhance tblgen's declarative assembly format to allow `attr-dict` in
custom directives.

Reviewed By: rriddle

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

In the OpenACC specification, there are two different self clause. One for the
update directive with a var-list argument. This clause is a synonym of the host clause.
The second self clause is present for most of the compute construct and takes an optional
condition. To solve this ambiguity, the self clause for the update directive is directly
translated to a host clause during the parsing. The self clause in AccClause refers always
to the compute construct clause.

Reviewed By: kiranktp

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

This reverts commit bcb8a119.

+fix rocm runner

Reviewed By: mehdi_amini

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

Summary:
Propagate driver commandline remarks options to linker when LTO is enabled.

This gives novice user a convenient way to collect and filter remarks throughout
a typical toolchain invocation with sample profile and LTO using single switch
from the clang driver.

A typical use of this option from clang command-line:

* Using -Rpass* options to print remarks to screen:

  clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt
   -Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline
   -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp

  Remarks will be dumped to screen from both pre-lto and lto
  compilation.

* Using serialized remarks options

  clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt
   -fsave-optimization-record
   -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp

  This will produce multiple yaml files containing optimization remarks:
  1. foo.opt.yaml : remarks from pre-lto
  2. foo.opt.ld.yaml.thin.1.yaml: remark during lto

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

Since Wasm comdat sections work similarly to ELF, we can use that mechanism
to eliminate duplicate dwarf type information in the same way.

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

If `null_pointer_is_valid` is present, `dereferenceable` does not imply
`nonnull`, make it clear.

Came up in D17993.

Reviewed By: aqjune

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

Reported by Colleen Bertoni <bertoni@anl.gov> after running the OvO test
suite: https://github.com/TApplencourt/OvO/

The template overload is still hidden behind an ifdef for OpenMP. In the
future we probably want to remove the ifdef but that requires further
testing.

Reviewed By: JonChesterfield, tra

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

Reviewed By: lntue

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

[BranchProbabilityInfo] Make MaxSuccIdx[Src] efficient and add a comment about the subtle eraseBlock. NFC

Follow-up to D90272.

Resolves missed comments in D89103

At this point, these methods are just carbon copies of OpBuilder::create and aren't necessary given that PatternRewriter inherits from OpBuilder.

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

An InterfaceMap is generated for every single operation type, and is responsible for a large amount of the code size from MLIR given that its internals highly utilize templates. This revision refactors the internal implementation to use bare malloc/free for interface instances as opposed to static variables and moves as much code out of templates as possible. This led to a decrease of over >1mb (~12% of total MLIR related code size) for a downstream MLIR library with a large amount of operations.

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

When compiling for code size, the use of a vtable causes a destructor(and constructor in certain cases) to be generated for the class. Interface models don't need a complex constructor or a destructor, so this can lead to many megabytes of code size increase(even in opt). This revision switches to a simpler struct of function pointers approach that accomplishes the same API requirements as before. This change requires no updates to user code, or any other code aside from the generator, as the user facing API is still exactly the same.

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