[ArgPromotion][Attributor] Update min-legal-vector-width when do promotion

X86 codegen uses function attribute `min-legal-vector-width` to select the proper ABI. The intention of the attribute is to reflect user's requirement when they passing or returning vector arguments. So Clang front-end will iterate the vector arguments and set `min-legal-vector-width` to the width of the maximum for both caller and callee.

It is assumed any middle end optimizations won't care of the attribute expect inlining and argument promotion.
- For inlining, we will propagate the attribute of inlined functions because the inlining functions become the newer caller.
- For argument promotion, we check the `min-legal-vector-width` of the caller and callee and refuse to promote when they don't match.

The problem comes from the optimizations' combination, as shown by https://godbolt.org/z/zo3hba8xW. The caller `foo` has two callees `bar` and `baz`. When doing argument promotion, both `foo` and `bar` has the same `min-legal-vector-width`. So the argument was promoted to vector. Then the inlining inlines `baz` to `foo` and updates `min-legal-vector-width`, which results in ABI mismatch between `foo` and `bar`.

This patch fixes the problem by expanding the concept of `min-legal-vector-width` to indicator of functions arguments. That says, any passes touch functions arguments have to set `min-legal-vector-width` to the value reflects the width of vector arguments. It makes sense to me because any arguments modifications are ABI related and should response for the ABI compatibility.

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

[flang] Added tests for taskwait and taskyield translation

Reviewed By: kiranchandramohan

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

Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>

[LoopCacheAnalysis] Use stable_sort() to avoid non-deterministic print output

The print output of loop cache analysis sometimes has a non-deterministic order
and therefore we have been using `CHECK-DAG` in its lit tests. This patch changes
the sorting of LoopCosts to llvm::stable_sort() where we compare loop cost numbers
and sort the loops. In case of the same loop cost numbers, llvm::stable_sort() now
would output a deterministic loop order.

Reviewed By: Meinersbur, fhahn, #loopoptwg

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

[clang][preprocessor] Add more macros to target AVR

Reviewed By: MaskRay, aykevl

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

[Driver][Ananas] -r: imply -nostdlib like GCC

Similar to D116843 for Gnu.cpp

Reviewed By: zhmu, MaskRay

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

[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target=

Similar to D119309

[compiler-rt][builtins] Add several helper functions for AVR

__mulqi3 : int8 multiplication
__mulhi3 : int16 multiplication
   _exit : golobal terminator

Reviewed By: MaskRay, aykevl

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

[gn build] Port 3939e99aae68

llvm-reduce: Fix not removing first instruction in MachineBasicBlock

This had the surprising behavior of using whatever instruction
happened to be first in the block as an anchor point to stick random
implicit defs on. Use a real implicit_def instead.

llvm-reduce: Introduce new scoring mechanism for MIR reductions

Many MIR reductions benefit from or require increasing the instruction
count. For example, unlike in the IR, you may need to insert a new
instruction to represent an undef. The current instruction reduction
pass works around this by sticking implicit defs on whatever
instruction happens to be first in the entry block block.

Other strategies I've applied manually include breaking instructions
with multiple defs into separate instructions, or breaking large
register defs into multiple subregister defs.

Make up a simple scoring system based on what I generally try to get
rid of first when manually reducing. Counts implicit defs as free
since reduction passes will be introducing them, although they
probably should count for something. It also might make more sense to
have a comparison the two functions, rather than having to compute a
contextless number. This isn't particularly well tested since overall
the MIR support isn't in a place where it is useful on the kinds of
testcases I want to throw at it.

llvm-reduce: Do not try to delete frame instructions

The verifier enforces these appearing as balanced pairs, so just
deleting one has no real chance of producing something valid.

llvm-reduce: Add pass to reduce IR references from MIR

This is typically the first thing I do when reducing a new testcase
until the IR section can be deleted.

[RISCV] Lower case the first letter of LowerRISCVMachineOperandToMCOperand. NFC

doc: update of the adv build doc now that clang is in tree too
And be more consistent in the declarations

[mlir:PDLInterp] Refactor the implementation of result type inferrence

The current implementation uses a discrete "pdl_interp.inferred_types"
operation, which acts as a "fake" handle to a type range. This op is
used as a signal to pdl_interp.create_operation that types should be
inferred. This is terribly awkward and clunky though:

* This op doesn't have a byte code representation, and its conversion
  to bytecode kind of assumes that it is only used in a certain way. The
  current lowering is also broken and seemingly untested.

* Given that this is a different operation, it gives off the assumption
  that it can be used multiple times, or that after the first use
  the value contains the inferred types. This isn't the case though,
  the resultant type range can never actually be used as a type range.

This commit refactors the representation by removing the discrete
InferredTypesOp, and instead adds a UnitAttr to
pdl_interp.CreateOperation that signals when the created operations
should infer their types. This leads to a much much cleaner abstraction,
a more optimal bytecode lowering, and also allows for better error
handling and diagnostics when a created operation doesn't actually
support type inferrence.

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

[SimpleLoopUnswitch] Freeze individual OR/AND operands.

In some cases, it is not enough to freeze the final AND/OR operation
when chaining a number of invariant conditions together.

After creating a chain of ANDs/ORs, we assume all unswitched operands to
be either true or false. But if any of the operands is poison, the rest
of the operands could have any value after branching on the frozen
condition.

To avoid that, freeze individual operands, if needed. In some cases this
may lead to unnecessary freezes, but it seems required at least for some
cases (see trivial-unswitch-freeze-individual-conditions.ll)

Reviewed By: nikic

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

[VectorCombine] Merge isa<>/cast<> into dyn_cast<>. NFC.

We want to handle the the assert in VectorCombine so avoid the repeated isa/cast code.

[Polly] Fix test after D119669.

[DAG] (style) Break apart if-else chain as they all return

[clang][dataflow] Optimize flow condition representation

Enable efficient implementation of context-aware joining of distinct
boolean values. It can be used to join distinct boolean values while
preserving flow condition information.

Flow conditions are represented as Token <=> Clause iff formulas. To
perform context-aware joining, one can simply add the tokens of flow
conditions to the formula when joining distinct boolean values, e.g:
`makeOr(makeAnd(FC1, Val1), makeAnd(FC2, Val2))`. This significantly
simplifies the implementation of `Environment::join`.

This patch removes the `DataflowAnalysisContext::getSolver` method.
The `DataflowAnalysisContext::flowConditionImplies` method should be
used instead.

Reviewed-by: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D124395

[X86] (style) Use auto for dyn_cast<> results

[X86] (style) Don't use auto for non obvious types

[SLPVectorizer] Remove weird unicode character from comment. NFCI.

Whatever it was, Visual Assist really didn't like it....

[InstCombine] Add test coverage from D124503

[Coroutines] Regenerate coro-retcon-resume-values.ll

[LoopVectorize][X86] Regenerate invariant-store-vectorization.ll

[analyzer] Fix return of llvm::StringRef to destroyed std::string

This issue was discovered whilst testing with ASAN.

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

[CostModel][X86] Check for 'null op' truncations

If the legalized src/dst types are the same, assume the "truncation" is free.

This fixes some edge cases such as mul lo/hi ops and bool vectors which will get legalized back to legal vector widths

[libc++][NFC] Replace _LIBCPP_INLINE_VISIBILTIY and _VSTD in <string>

Replace all the instances of `_LIBCPP_INLINE_VISIBILITY` with `_LIBCPP_HIDE_FROM_ABI` and `_VSTD` with `std`.

Reviewed By: Mordante, #libc

Spies: libcxx-commits

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

[flang] Add one semantic check for implicit interface

As Fortran 2018 C1533, a nonintrinsic elemental procedure shall not be
used as an actual argument. The semantic check for implicit iterface is
missed.

Reviewed By: klausler

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

[clang-format] Take out common code for parsing blocks NFC

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

[CostModel][X86] Reduce cost of vector selects on SSE2/AVX1 targets

Based off the script from D103695, we were exaggerating the cost of the OR(AND(X,M),AND(Y,~M)) expansion using instruction count instead of effective throughput

[clang-tidy][NFC] Re-alphabetize the clang tidy release notes

[CAPI] Expose CastInst::getCastOpcode in C API

Reviewed By: deadalnix

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

[NVPTX] Prefix "$L__" for branch label names

A global variable may have the same name as a label, and ptxas does not accept it.
Prefix labels with $L__ to fix this.

Reviewed By: MaskRay, tra

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

[LV] Add test for interleaving multiple iterations with call.

[PhaseOrdering][X86] Use passes="" instead of passes='' so DOS can evaluate the cmd lines

Fix regenerating the tests on windows builds

[SimpleLoopUnswitch] Freeze trivial conditions if needed.

Trivial unswitching can also introduce new branches on undef/poison.
Freeze the conditions if needed.

Reviewed By: nikic

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

[PhaseOrdering][X86] Use passes="default<O3>" instead of passes='default<O3>' so DOS can evaluate the cmd lines

Fix regenerating the tests on windows builds

[SLP][X86] extractelement tests - use -mattr=avx2 instead of a -march flag

[LegalizeDAG] Fix TypeSize conversion error when expanding SIGN_EXTEND_INREG

SIGN_EXTEND_INREG expansion can trigger a TypeSize error because
"VT.getSizeInBits() == 1" is used to detect for a boolean without
first verifying VT is a scalar.

[DAGCombiner] When matching a disguised rotate by constant don't forget to apply LHSMask/RHSMask.

We try to match as a disguised rotate by constant of these forms
(shl (X | Y), C1) | (srl X, C2) --> (rotl X, C1) | (shl Y, C1)
(shl X, C1) | (srl (X | Y), C2) --> (rotl X, C1) | (srl Y, C2)

We may have also looked through an AND to find the shift. If we
did, we need to apply a mask to the result.

I'll add an AArch64 test and pre-commit it and the RISC-V test
tomorrow.

Fixes PR55201.

Reviewed By: RKSimon

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

[RISCV][AArch64] Pre-commit tests for D124711. NFC

Accept -fno-knr-functions as a driver flag as well

Due to a think-o, it was only being accepted as a -cc1 flag. This adds
the proper forwarding from the driver to the frontend and adds test
coverage for the option.

[RISCV] Don't getDebugLoc for the end node of MBB iterator

Because of shrink wrapping, the block to insert epilog may don't have
instructions (Only debug instructions). And the position to insert may
point to MBB.end() that don't have a DebugLoc. This patch fix this
problem.

The test program was copied from the issue:https://github.com/llvm/llvm-project/issues/53662

Reviewed By: luismarques

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

AArch64: modify Swift async frame record storage on Windows

The frame layout on Windows differs from that on other platforms. It
will spill the registers in descending numeric value (i.e. x30, x29,
...). Furthermore, the x29, x30 pair is particularly important as it
is used for the fast stack walking. As a result, we cannot simply
insert the Swift async frame record in between the store. To provide
the simplistic search mechanism, always spill the async frame record
prior to the spilled registers.

This was caught by the assertion failure in the frame lowering code when
building the runtime for Windows AArch64.

Fixes: #55058

Differential Revision: https://reviews.llvm.org/D124498
Reviewed By: mstorsjo

Generalize calls to ImplicitlyDefineFunction

In C++ and C2x, we would avoid calling ImplicitlyDefineFunction at all,
but in OpenCL mode we would still call the function and have it produce
an error diagnostic. Instead, we now have a helper function to
determine when implicit function definitions are allowed and we use
that to determine whether to call ImplicitlyDefineFunction so that the
behavior is more consistent across language modes.

This changes the diagnostic behavior from telling the users that an
implicit function declaration is not allowed in OpenCL to reporting use
of an unknown identifier and going through typo correction, as done in
C++ and C2x.

[MLIR][Presburger] subtraction: add support for divs defined by equalties

Reviewed By: Groverkss

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

Revert "[msan][libcxx] Enable -fsanitize-memory-param-retval"

This reverts commit beff64ee44acec4e7bfbc2ab165acba7579a6bb7.

The original commit was reviewed as D123979.

This commit caused the libc++ pre-commit CI to fail
https://buildkite.com/llvm-project/libcxx-ci/builds/10483

Reviewed By: #libc, Mordante

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

[InstCombine] Remove the undef-related workaround code in visitSelectInst

This patch removes an old hack in visitSelectInst that was written to avoid miscompilation bugs in loop unswitch.
(Added via https://reviews.llvm.org/D35811)

The legacy loop unswitch pass will be removed after D124376, and the new simple loop unswitch pass correctly uses freeze to avoid introducing UB after D124252.

Since the hack is not necessary anymore, this patch removes it.

Reviewed By: nikic

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

Add a pre-commit test for D124426

[X86] lowerShuffleAsRepeatedMaskAndLanePermute - permit 32-bit sublane permute for unary v32i8 cases

Increase the likelihood that we can lower to a permd(pshufb()) pattern, but only after we've attempted with 64-bit sublane permutes first

Fixes #55066

Reland [clangd] More precisely enable clang warnings through ClangTidy options

This reverts commit 26c82f3d1de11cdada57e499b63a05d24e18b656.

When tests enable 'Checks: *', we may get extra diagnostics.

ClangDriverTests:ToolChainTest.cpp: Fix warnings. [-Wsign-compare]

EXPECT_EQ(num,num) is aware of signedness, even if rhs is a constant.

[RISCV] Add DAGCombine to fold base operation and reduction.

Transform (<bop> x, (reduce.<bop> vec, splat(neutral_element))) to
(reduce.<bop> vec, splat (x)).

Reviewed By: craig.topper

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

[BOLT][NFC] Reduce Target/{AArch64,X86} dependencies

We don't actually depend on entire X86/AArch64 components that pull in CodeGen,
SelectionDAG etc., just the Desc part with opcode and other definitions.

Note that it doesn't decouple BOLT from these components - we still pull in X86
and AArch64 from top-level llvm-bolt dependencies as we use assembler and
disassembler. It's difficult to reduce these as this requires non-trivial
changes to X86/AArch64 components themselves (e.g. moving out AsmPrinter).

Reviewed By: rafauler

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

[RISCV] Fix int16 -> __fp16 conversion code gen

clang emit wrong code sequence for `int16`(`short`) to `__fp16` conversion,
and that should fix the code gen directly is the right way I think,
but I found there is a FIXME comment in clang/Basic/TargetInfo.h say
that's should be removed in future so I think just let swich to using
generic LLVM IR rather than llvm.convert.to.fp16 intrinsics code gen
path is enough.

```
  /// Check whether llvm intrinsics such as llvm.convert.to.fp16 should be used
  /// to convert to and from __fp16.
  /// FIXME: This function should be removed once all targets stop using the
  /// conversion intrinsics.
  virtual bool useFP16ConversionIntrinsics() const {
    return true;
  }
```

Reviewed By: craig.topper

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

[RISCV] Precommit test for D124509

Test case to show the wrong code gen for `int16` -> `__fp16` conversion,
clang just emit a load and store without did conversion in the case,

and another case used for demonstrate the code gen change of `__fp16`
-> `int16`.

Reviewed By: khchen

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

[OpenMP] Fix printing commands twice in verbose mode

Summary:
A previous patch merged the command execution and printing into a helper
function. The old printing code wasn't removed causing each to be
printed twice.

[compiler-rt][profile][RISCV] Enable profile for RISC-V

Profile library are written by standard libraries or POSIX calls depend on target support, so there is no porting effort for the target, we could enable that for both RV32 and RV64, verified on the RV64 platform.

Reviewed By: MaskRay

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

[RISCV] Copy test from mem.ll to mem64.ll for completeness. NFC

Add nounwind to both copies.

Addresses post-commit feedback from f91690f7db96aae16425241a17fe6649f5d156b4

[RISCV] Don't merge addi into load/store address if addi has a FrameIndex operand.

This fixes a crash from D124231.

We can't fold
  (load (add base, (addi src, off1)), off2)
     -> (load (add base, src), off1+off2)
if the src is a FrameIndex. FrameIndex cannot be the operand of an
add.

There was an immediate==0 check that I think was trying to catch
the common case of FrameIndex addis where the immediate is 0, but
they can also appear in non-zero form. Instead explicitly check
for a FrameIndex operand.

[gn build] Port 73417c517644

[RISCV] Remove 'frameindex' from list for ComplexPattern. NFC

Putting a node in this list allows the node to be used as the root
of an isel pattern that would then call the ComplexPattern. The
usual case is to use the ComplexPattern as the operand of another
operator.

AddrFI is never used as a root operation. frameindex is handled
directly with custom code in RISCVISelDAGToDAG::Select. So adding
frameindex to the list here serves no purpose.

Revert "[clangd] More precisely enable clang warnings through ClangTidy options"

This reverts commit 5227be8b6aa0edb2edb0b76e1039a7dd5641c80a.
Broke check-clangd, see comment on https://reviews.llvm.org/D124679

[CSSPGO] Turn on priority inlining for probe-only profile

We have seen that the prioirty inliner delivered on-par performance with the old inliner for probe-only CSSPGO profile, as long as without a size budget. I'm turning on the priority inliner for probe-only profile by default.

Reviewed By: wenlei

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

[SelectionDAG] Pre-commit test for D124696. NFC

[RISCV]Add CTZ Intrinsic for ZBB in Clang

Add Intrinsics and test for B extension (updating coming soon (:

Reviewed By: craig.topper

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

[CSSPGO] Rename ProfileIsCSNested and ProfileIsCSFlat

To be more clear and definitive, I'm renaming `ProfileIsCSFlat` back to `ProfileIsCS` which stands for full context-sensitive flat profiles.  `ProfileIsCSNested` is now renamed to `ProfileIsPreInlined` and is extended to be applicable for CS flat profiles too. More specifically, `ProfileIsPreInlined` is for any kind of profiles (flat or nested) that contain 'ShouldBeInlined' contexts. The flag is encoded in the profile summary section for extbinary profiles and is computed on-the-fly for text profiles.

Reviewed By: wenlei

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

[HLSL][clang][Driver] Support validator version command line option.

The DXIL validator version option(/validator-version) decide the validator version when compile hlsl.
The format is major.minor like 1.0.

In normal case, the value of validator version should be got from DXIL validator. Before we got DXIL validator ready for llvm/main, DXIL validator version option is added first to set validator version.

It will affect code generation for DXIL, so it is treated as a code gen option.

A new member std::string DxilValidatorVersion is added to clang::CodeGenOptions.

Then CGHLSLRuntime is added to clang::CodeGenModule.
It is used to translate clang::CodeGenOptions::DxilValidatorVersion into a ModuleFlag under key "dx.valver" at end of clang code generation.

Reviewed By: beanz

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

Test commit. Fixed a typo in a comment.

[libc] Add implementations of feof, ferror and clearerr.

The corresponding _unlocked functions have also been added.

Reviewed By: lntue, michaelrj

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

[LoopCacheAnalysis] Minor test case update

Changed the test case in https://reviews.llvm.org/D122857
from using `CHECK` to using `CHECK-DAG` to incorporate
nondeterministic output.

[Driver] Support for compressed debug info on Fuchsia

Pass the --compress-debug-sections=zlib argument to the linker when
the use of compressed debug info is requested.

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

[NVPTX] Add add.cc/addc.cc/sub.cc/subc.cc for i64

PTX supports those instructions for i64 starting from 4.3.
The patch also marks corresponding DAG nodes legal for both i32 and i64.

Reviewed By: tra

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

[MIPS] Address instruction selection failure for abs.[sd]

Previously, the choice between the instruction selection of ISD::FABS was
decided at the point of setting the MIPS target lowering operation choice
either `Custom` lowering or `Legal`. This lead to instruction selection
failures as functions could be marked as having no NaNs.

Changing the lowering to always be `Custom` and directly handling the
the cases where MIPS selects the instructions for ISD::FABS resolves
this crash.

Thanks to kray for reporting the issue and to Simon Atanasyan for producing
the reduced test case.

This resolves PR/53722.

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

LocationListLookup test case failing on lldb-arm-ubuntu

Skip on linux+arm for now until I can try to repo the setup of the
lldb-arm-ubuntu bot.  The name of the binary in argv[0] was not
able to be retrieved here; if the compiler's codegen had it stored
in a caller saved register, because it's not needed at this point,
it may not be retreivable.

Decr pc when looking for DWARF loc list entry mid-stack

When looking for a variable location in a DWARF location list,
we search the list of ranges to find one that includes the pc.
With a function mid-stack, the "pc" is the return pc instead of
the call instruction, and in optimized code this can be another
function or a different basic block (with different variable
locations).  Back up the "pc" value mid-stack to find the correct
location list entry.

Differential Revision: https://reviews.llvm.org/D124597
rdar://63903416

Revert "[JumpThreading][NFC][CompileTime] Do not recompute BPI/BFI analyzes"

This change has caused non-reproducibility of a self-build of Clang
when using NewPM and providing profile data.

This reverts commit 35f38583d2f2484794f579bed69566b40e732206.

Thread safety analysis: Don't pass capability kind where not needed (NFC)

If no capability is held, or the capability expression is invalid, there
is obviously no capability kind and so none would be reported.

Reviewed By: aaron.ballman

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

Thread safety analysis: Store capability kind in CapabilityExpr

This should make us print the right capability kind in many more cases,
especially when attributes name multiple capabilities of different kinds.

Previously we were trying to deduce the capability kind from the
original attribute, but most attributes can name multiple capabilities,
which could be of different kinds. So instead we derive the kind when
translating the attribute expression, and then store it in the returned
CapabilityExpr. Then we can extract the corresponding capability name
when we need it, which saves us lots of plumbing and almost guarantees
that the name is right.

I didn't bother adding any tests for this because it's just a usability
improvement and it's pretty much evident from the code that we don't
fall back to "mutex" anymore (save for a few cases that I'll address in
a separate change).

Reviewed By: aaron.ballman

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

Thread safety analysis: Store CapabilityExprs in ScopedLockableFactEntry (NFC)

For now this doesn't make a whole lot of sense, but it will allow us to
store the capability kind in a CapabilityExpr and make sure it doesn't
get lost. The capabilities managed by a scoped lockable can of course be
of different kind, so we'll need to store that per entry.

Reviewed By: aaron.ballman

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

Thread safety analysis: Pack CapabilityExpr using PointerIntPair (NFC)

We're storing these quite frequently: FactEntry inherits from
CapabilityExpr, and the FactManager has a vector of such entries.

Reviewed By: aaron.ballman

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

[clangd] More precisely enable clang warnings through ClangTidy options

clang-tidy's behavior is to add the -W flags, and then map all clang diagnostics
to "clang-diagnostic-foo" pseudo-check-names, then use Checks to filter those.

Previous to this patch, we were handling -W flags but not filtering the
diagnostics, assuming both sets of information encoded the same thing.

However this intersection is nontrivial when diagnostic group hierarchy is
involved. e.g. -Wunused + clang-diagnostic-unused-function should not enable
unused label warnings.

This patch more closely emulates clang-tidy's behavior, while not going to
the extreme of generating tidy check names for all clang diagnostics and
filtering them with regexes.

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

[LoopCacheAnalysis] Enable delinearization of fixed sized arrays

Currently loop cache cost (LCC) cannot analyze fix-sized arrays
since it cannot delinearize them. This patch adds the capability
to delinearize fix-sized arrays to LCC. Most of the code is ported
from DependenceAnalysis.cpp and some refactoring will be done in a
next patch.

Reviewed By: #loopoptwg, Meinersbur

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

[InstCombine] add tests for FP<->int casts; NFC

This overlaps with at least some existing tests,
but the smaller types should be faster for alive2
to verify. We know that at least one of these is
currently wrong (miscompile) as shown in #55150.

[AsmParser] Introduce a new "Argument" abstraction + supporting logic

MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adhoc ways throughout the codebase.  The approach this uses
is verbose (because it is implemented with parallel arrays) and
inconsistent (e.g. lots of things drop source location info).

Solve this by introducing OpAsmParser::Argument and make addRegion
(which sets up BlockArguments for the region) take it.  Convert the
world to propagating this down.  This means that we correctly
capture and propagate source location information in a lot more
cases (e.g. see the affine.for testcase example), and it also
simplifies much code.

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

[memprof] Correct comment in test [NFC]

Correct comment referring incorrectly to address sanitizer (from which
the memprof tests were originally forked).

[flang] Update Google Doc link for Flang Biweekly Sync call notes

Notes from the Flang Biweekly Sync calls have been merged into the same document as the notes from the Flang Technical calls. This patch updates the link in the GettingInvolved document to point to the new location.

Reviewed By: jdoerfert

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

[lldb] Fix initialization of LazyBool/bool variables m_overwrite/m_overwrite_lazy. NFCI.

This silences a GCC warning after
1f7b58f2a50461493f083b2ed807b25e036286f6 / D122680:

lldb/source/Commands/CommandObjectCommands.cpp:1650:22: warning: enum constant in boolean context [-Wint-in-bool-context]
 1650 |   bool m_overwrite = eLazyBoolCalculate;
      |                      ^~~~~~~~~~~~~~~~~~

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

Fix the encoding and decoding of UniqueCStringMap<T> objects when saved to cache files.

UniqueCStringMap<T> objects are a std::vector<UniqueCStringMap::Entry> objects where the Entry object contains a ConstString + T. The values in the vector are sorted first by ConstString and then by the T value. ConstString objects are simply uniqued "const char *" values and when we compare we use the actual string pointer as the value we sort by. This caused a problem when we saved the symbol table name indexes and debug info indexes to disk in one process when they were sorted, and then loaded them into another process when decoding them from the cache files. Why? Because the order in which the ConstString objects were created are now completely different and the string pointers will no longer be sorted in the new process the cache was loaded into.

The unit tests created for the initial patch didn't catch the encoding and decoding issues of UniqueCStringMap<T> because they were happening in the same process and encoding and decoding would end up createing sorted UniqueCStringMap<T> objects due to the constant string pool being exactly the same.

This patch does the sort and also reserves the right amount of entries in the UniqueCStringMap::m_map prior to adding them all to avoid doing multiple allocations.

Added a unit test that loads an object file from yaml, and then I created a cache file for the original file and removed the cache file's signature mod time check since we will generate an object file from the YAML, and use that as the object file for the Symtab object. Then we load the cache data from the array of symtab cache bytes so that the ConstString "const char *" values will not match the current process, and verify we can lookup the 4 names from the object file in the symbol table.

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

[AMDGPU][clang] Definition of gfx11 subtarget

Contributors:
Jay Foad <jay.foad@amd.com>
Konstantin Zhuravlyov <kzhuravl_dev@outlook.com>

Patch 2/N for upstreaming of AMDGPU gfx11 architecture

Depends on D124536

Reviewed By: foad, kzhuravl, #amdgpu, arsenm

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

[AMDGPU] Produce waitcounts for LDS DMA

MUBUF and FLAT LDS DMA operations need a wait on vmcnt before LDS written
can be accessed. A load from LDS to VMEM does not need a wait.

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

[flang] Fix build bot problem

A recent change is eliciting a valid warning from the out-of-tree
flang build bot; fix by using a reference in a range-based for().

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

Add a paragraph showing how to use container commands.

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

[mlir] Prevent argStorage relocations

This fixes msan reports like https://reviews.llvm.org/P8285

Reviewed By: rriddle

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

Add a mutex to the ThreadPlanStackMap class.
We've seen very occasional crashes that we can only explain by
simultaneous access to the ThreadPlanStackMap, so I'm adding a
mutex to protect it.

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

[randstruct] Automatically randomize a structure of function pointers

Strutures of function pointers are a good surface area for attacks. We
should therefore randomize them unless explicitly told not to.

Reviewed By: aaron.ballman, MaskRay

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

Fix sphinx build error in AMDGPUUsage.rst

Corrects error from
813e521e55b11165138b071f446eda94b14570dc

Reapply [CodeGen][ARM] Enable Swing Module Scheduling for ARM

Fixed "private field is not used" warning when compiled
with clang.

original commit: 28d09bbbc3d09c912b54a4d5edb32cab7de32a6f
reverted in: fa49021c68ef7a7adcdf7b8a44b9006506523191

------

This patch permits Swing Modulo Scheduling for ARM targets
turns it on by default for the Cortex-M7.  The t2Bcc
instruction is recognized as a loop-ending branch.

MachinePipeliner is extended by adding support for
"unpipelineable" instructions.  These instructions are
those which contribute to the loop exit test; in the SMS
papers they are removed before creating the dependence graph
and then inserted into the final schedule of the kernel and
prologues. Support for these instructions was not previously
necessary because current targets supporting SMS have only
supported it for hardware loop branches, which have no
loop-exit-contributing instructions in the loop body.

The current structure of the MachinePipeliner makes it difficult
to remove/exclude these instructions from the dependence graph.
Therefore, this patch leaves them in the graph, but adds a
"normalization" method which moves them in the schedule to
stage 0, which causes them to appear properly in kernel and
prologues.

It was also necessary to be more careful about boundary nodes
when iterating across successors in the dependence graph because
the loop exit branch is now a non-artificial successor to
instructions in the graph. In additional, schedules with physical
use/def pairs in the same cycle should be treated as creating an
invalid schedule because the scheduling logic doesn't respect
physical register dependence once scheduled to the same cycle.

Reviewed By: dmgreen

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