The dimension order of a filter in tensorflow is
[filter_height, filter_width, in_channels, out_channels], which is different
from current definition. The current definition follows TOSA spec. Add TF
version conv ops to .tc, so we do not have to insert a transpose op around a
conv op.

Reviewed By: antiagainst

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

Some parameters were already part of the Config passed in.

This should have gone in with a76761cf.

 - Remove leftover comment from de2568aa
 - Fix a typo in a comment

Function `replaceMathCmpWithIntrinsic` artificially limits the scope
of the optimization, setting a requirement of two instructions be in
the same block, due to two reasons:
- usage of DT for more general check is costly in terms of compile time;
- risk of creating a new value that lives through multiple blocks.

Because of this, two semantically equivalent tests may be or not be the
subject of this opt depending on where the binary operation is located.
See `test/CodeGen/X86/usub_inc_iv.ll` for motivation

There is one important particular case where this limitation is  too strict:
it is when the binary operation is the increment of the induction variable.
As result, the application of this opt becomes fragile and highly reliant on
where other passes decide to place IV increment. In most cases, they place
it in the end of the latch block, killing the opt opportunity (when in fact it
does not matter where to insert the actual instruction).

This patch handles this particular case separately.
- The detector does not use dom tree and has constant cost;
- The value of IV or IV.next lives through all loop in any case, so this should not
  create a new unexpected long-living value.

As result, the transform becomes more robust. It also seems to lead to
better code generation in some cases (see `test/CodeGen/X86/lsr-loop-exit-cond.ll`).

Differential Revision: https://reviews.llvm.org/D96119
Reviewed By: spatel, reames

GCC warning:
```
/llvm-project/clang/lib/Frontend/TestModuleFileExtension.cpp:131:20: warning: ‘llvm::raw_ostream& clang::operator<<(llvm::raw_ostream&, const clang::TestModuleFileExtension&)’ has not been declared within ‘clang’
  131 | llvm::raw_ostream &clang::operator<<(llvm::raw_ostream &OS,
      |                    ^~~~~
In file included from /llvm-project/clang/lib/Frontend/TestModuleFileExtension.cpp:8:
/llvm-project/clang/lib/Frontend/TestModuleFileExtension.h:75:3: note: only here as a ‘friend’
   75 |   operator<<(llvm::raw_ostream &OS, const TestModuleFileExtension &Extension);
      |   ^~~~~~~~
```

Add mimgopc object to represent the opcode allowing different
opcodes for different hardware variants.
This enables image_atomic_fcmpswap, image_atomic_fmin, and
image_atomic_fmax on GFX10

Reviewed By: foad, rampitec

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

Move SimplifiyVisitor from Simplify.h to Simplify.cpp. It is not
relevant for applying the pass in either the NewPM or the legacyPM.
Rename it to SimplifyImpl to account for that.

This is possible due its state not being necessary to be preserved
between runs and thefore SimplifyImpl not needed to be held in the
pass object. Instead, SimplifyImpl is only instatiated for the
current Scop. In the NewPM as a function-local variable, and in the
legacy PM inside a llvm::Optional object because the state must be
preserved between the printScop (invoked by opt -analyze) and the most
recent runOnScop calls.

Identified with readability-const-return-type.

This removes the commuted PatFrags that only existed to carry
an SDNodeXForm in its OperandTransform field. We know all the places
that need to use the commuted SDNodeXForm and there is one transform
shared by signed and unsigned compares. So just hardcode the
the SDNodeXForm where it is needed and use the non commuted PatFrag
in the pattern.

I think when I wrote this I thought the SDNodeXForm name had to
match what is in the PatFrag that is being used. But that's not
true. The OperandTransform is only used when the PatFrag is used
in an instruction pattern and not a separate Pat pattern. All
the commuted cases are Pat patterns.

"using namespace" pollutes the namespace of every file that includes
such a header and universally considered a bad thing. Even the variant

    namespace polly {
      using namespace llvm;
    }

(previously used by LoopGenerators.h) imports more symbols than the file
is in control of. The header may include a fixed set of files from LLVM,
but the header itself may by be included together with other headers
from LLVM. For instance, LLVM's MemorySSA.h and Polly's ScopInfo.h both
declare a class 'MemoryAccess' which may conflict.

Instead of prefixing everything in Polly's header files, this patch adds
'using' statements to import only the symbols that are actually
referenced in Polly. This approach is also used by MLIR to import
commonly used symbols into the mlir namespace.

This patch also puts the symbols declared in IslNodeBuilder.h into the
Polly namespace to also be able to use the imported symbols.

Updates static analyzer to be able to generate both sarif and html
output in a single run similar to plist-html.

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

Rationale:
BuiltinTypes.cpp observed overflow when computing size of
tensor<100x200x300x400x500x600x700x800xf32>.

Reviewed By: stellaraccident

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

This binds the SDNodeXForm to the ImmLeaf so we only need to mention
the ImmLeaf in both the input and output pattern.

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

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

Reviewed By: mehdi_amini

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

When accessing a specific procedure of a USE-associated generic
interface, we need to allow for the case in which that specific
procedure has the same name as the generic when testing for
its availability in the current scope.

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

https://reviews.llvm.org/D95835 implements origin tracking for DFSan.
It reuses the chained origin depot of MSan.

This change moves the utility to sanitizer_common to share between
MSan and DFSan.

Reviewed-by: eugenis, morehouse

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

Some state in name resolution is stored in the DeclarationVisitor
instance and processed at the end of the specification part.
This state needs to accommodate nested specification parts, namely
the ones that can be nested in a subroutine or function interface
body.

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

An error has occurred when I build libunwind with -DLLVM_BUILD_DOCS=ON.

Reviewed By: #libunwind, compnerd

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

The CMake changes in 2aa1af9b to make it possible to build MLIR as a
standalone project unfortunately disabled all unit-tests from the
regular in-tree build.

Rename the `RF_MoveDistinctMDs` flag passed into `MapValue` and
`MapMetadata` to `RF_ReuseAndMutateDistinctMDs` in order to more
precisely describe its effect and clarify the header documentation.

Found this while helping to investigate PR48841, which pointed out an
unsound use of the flag in `CloneModule()`. For now I've just added a
FIXME there, but I'm hopeful that the new (more precise) name will
prevent other similar errors.

This is the first patch of a serie to move FIR types to TableGen format as suggested in D96172.
This patch is setting up the files for FIR types and move the ShapeType to TableGen.

As discussed with @schweitz, I'm taking over this task to help the FIR upstreaming effort.

Reviewed By: mehdi_amini

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

This test started failing after https://reviews.llvm.org/D95849
defaulted --allow-unused-prefixes to false.

Taking a look at the test, I didn't see an obvious need to add
OS-specific check lines for each supported value of %os.

rdar://74207657

A G_MUL + G_PTR_ADD can also be folded into a madd. So, conservatively, we
shouldn't combine when the G_MUL is used by a G_PTR_ADD either.

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

Added support for broadcasting size-1 dimensions for TOSA elemtnwise
operations.

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

Reviewed By: ychen

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

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

After discussion, it seems like we want to go with
"inherent/discardable". These seem to best capture the relationship with
the op semantics and don't conflict with other terms.

Please let me know your preferences. Some of the other contenders are:

```
"intrinsic" side | "annotation" side
-----------------+------------------
characteristic   | annotation
closed           | open
definitional     | advisory
essential        | discardable
expected         | unexpected
innate           | acquired
internal         | external
intrinsic        | extrinsic
known            | unknown
local            | global
native           | foreign
inherent         | acquired
```

Rationale:

- discardable: good. discourages use for stable data.
- inherent: good
- annotation: redundant and doesn't convey difference
- intrinsic: confusable with "compiler intrinsics".
- definitional: too much of a mounthful
- extrinsic: too exotic of a word and hard to say
- acquired: doesn't convey the relationship to the semantics
- internal/external: not immediately obvious: what is internal to what?

- innate: similar to intrinsic but worse
- acquired: we don't typically think of an op as "acquiring" things
- known/unknown: by who?
- local/global: to what?
- native/foreign: to where?
- advisory: confusing distinction: is the attribute itself advisory or
  is the information it provides advisory?
- essential: an intrinsic attribute need not be present.
- expected: same issue as essential
- unexpected: by who/what?
- closed/open: whether the set is open or closed doesn't seem essential
  to the attribute being intrinsic. Also, in theory an op can have an
  unbounded set of intrinsic attributes (e.g. `arg<N>` for func).
- characteristic: unless you have a math background this probably
  doesn't make as much sense

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

Follow up to https://reviews.llvm.org/rG483ec136da7193de781a5284f1c37929cc27c05c