17 vs 14 have different ASTs, this causes D131465 to have to touch this test.
While here, make sure we're being clear about *which* nodes we're matching.

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

This speeds up clangd's buildAST() (i.e. parsing with a preamble) by 5% on
clangd/AST.cpp, by avoiding filling up the diagnostic state map with entries for
all the files where templates are being instantiated from.

(I would assume it has a similar effect on PCH and modules compiles).

This approach is obviously pretty fragile, and we should find ways to make
isIgnored() cheaper instead. But these changes in particular don't seem to make
the code worse in any case.

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

Currently, one-shot-bufferize crashes as soon as there's
a mixture of tensor and non-tensor arguments. This seems
to happen for no good reason.

Reviewed By: springerm

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

Canonicalization for complex.sub adding same numbers. This canonicalization supports the case like complex.sub(complex.add(a, b), b) -> a.

Reviewed By: pifon2a

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

Use roundToIntegral instead roundeven of libm to avoid window build failed.

Reviewed By: mehdi_amini

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

This transform came up as a potential DAGCombine in D133282,
so I wanted to see how it escaped in IR too.

We do general folds in InstCombiner::SimplifySelectsFeedingBinaryOp()
by checking if either arm of a select simplifies when the trailing
binop is threaded into the select.

So as long as one side simplifies, it's a good fold to combine a
negate and add into 1 subtract.

This is an example with a zero arm in the select:
https://alive2.llvm.org/ce/z/Hgu_Tj

And this models the tests with a cancelling 'not' op:
https://alive2.llvm.org/ce/z/BuzVV_

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

Currently, instructions in the preheader of the second of two fusion
candidates are sunk and hoisted whenever possible, to try to allow the
loops to fuse. Memory instructions are skipped, and are never sunk or
hoisted. This change adds memory instructions for sinking/hoisting
consideration.

This change uses DependenceAnalysis to check if a mem inst in the
preheader of FC1 depends on an instruction in FC0's header, across
which it will be hoisted, or FC1's header, across which it will be
sunk. We reject cases where the dependency is a data hazard.

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

CombiningKind was implemented before EnumAttr, so it reimplements the same behaviour with the custom code. Except for a few places, EnumAttr is a drop-in replacement.

Reviewed By: nicolasvasilache, pifon2a

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

This patch mostly reverts commit 70b37f4c which fixed PR50725.

In case of explicit consumption of multiple partially overlapping group
resources, the ResourceManager was not correctly checking pipeline
esources availability.

The fix for PR50725 only partially addressed a few instances of that issue.
This is a more general (although, technically slower) fix for that same issue.

It also fixes Issue #57548

Thanks to Haohai Wen for the small reproducible.

Fixes https://github.com/clangd/clangd/issues/706

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

For the few non type based intrinsic cases we can just check for !isTypeBasedOnly() to access the args directly.

I don't think we have a need to keep getTypeBasedIntrinsicInstrCost in BasicTTIImpl.h any more and can do a similar merge there as well - but it's a messier refactor and will take a while.

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

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

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

While vectors use insertelement, structs and arrays should use
insertvalue.

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

We can't use an IR input once the relevant constant expressions
are no longer supported. Use a bitcode file instead, which will
be auto-upgraded (the whole point of this code...)

Refactor static functions into class methods so they have access to TII, MRI
etc.

Call ConstantFoldUnaryInstruction() instead, to only produce a
result if it folds.

Interpret MD_pcsections in AsmPrinter emitting the requested metadata to
the associated sections. Functions and normal instructions are handled.

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

Propagate (most) PC sections metadata to MachineInstr when GlobalISel is
doing instruction selection.

This change results in support for architectures using GlobalISel (such
as -O0 with AArch64). Not all instructions may be supported yet, and
requires further target-specific handling (such as done for AArch64
pseudo-atomics). Expanding supported instructions is planned on a
case-by-case basis and new use cases for PC sections metadata.

Reviewed By: vitalybuka

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

When expanding IR atomics to target-specific atomics, copy all
!pcsections Metadata to expanded atomics automatically.

Reviewed By: vitalybuka

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

Propagate PC sections metadata to MachineInstr when FastISel is doing
instruction selection.

Reviewed By: vitalybuka

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

Don't create fneg expressions unless explicitly requested by IR or
bitcode.

In many places DebugLoc and PCSections metadata are just copied along to
propagate them through MachineInstrs. Simplify doing so by bundling them
up in a MIMetadata class that replaces the DebugLoc argument to most
BuildMI() variants.

The DebugLoc-only constructors allow implicit construction, so that
existing usage of `BuildMI(.., DL, ..)` works as before, and the rest of
the codebase using BuildMI() does not require changes.

NFC.

Reviewed By: vitalybuka

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

Add a new entry to SDNodeExtraInfo to propagate PCSections through
SelectionDAG.

Reviewed By: vitalybuka

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

Simplify instruction selection patterns for mad/mac:
- Use any_fmad consistently to make it clear that all patterns treat
  fmad and AMDGPUfmad_ftz identically.
- For mad, put the patterns on the instruction definitions. For mac the
  patterns are still out-of-line because we want to set AddedComplexity
  and to have special handling of the source modifiers.

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

Document (in comments) the optional fourth "stride" argument to the
sequence operator, which was added in svn r157416.

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

Use ConstantFoldUnaryOpOperand() instead. Also make the code below
robust against non-instruction users, just in case it doesn't fold.

We can use `getValueOrCreateConstantIndexOp` instead.

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

This file is auto-generated, it's a bit confusing for the maintainers to have it
in tree while it shouldn't be modified *and* already have a rule to be
generated.

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

Introduce mlir::hasEffect and refactor existing usage to use utility.
NFC.

Reviewed By: rriddle, mehdi_amini

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

Reviewed By: LuoYuanke

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