[docs] Describe reporting security issues on the chromium tracker.

To track security issues, we're starting with the chromium bug tracker
(using the llvm project there).

We considered using Github Security Advisories.  However, they are
currently intended as a way for project owners to publicize their
security advisories, and aren't well-suited to reporting issues.

This also moves the issue-reporting paragraph to the beginning of the
document, in part to make it more discoverable, in part to allow the
anchor-linking to actually display the paragraph at the top of the page.

Note that this doesn't update the concrete list of security-sensitive
areas, which is still an open item.  When we do, we may want to move the
list of security-sensitive areas next to the issue-reporting paragraph
as well, as it seems like relevant information needed in the reporting
process.

Finally, when describing the discission medium, this splits the topics
discussed into two: the concrete security issues, discussed in the
issue tracker, and the logistics of the group, in our mailing list,
as patches on public lists, and in the monthly sync-up call.

While there, add a SECURITY.md page linking to the relevant paragraph.

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

[Remarks] Add analysis remarks for memset/memcpy/memmove lengths

Differential revision: https://reviews.llvm.org/D102452

[MC][ARM] Reject Thumb "ror rX, #0"

The ROR instruction can only handle immediates between 1 and 31. The
would-be encoding for ROR #0 is actually the RRX instruction.

Reviewed By: nickdesaulniers

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

[CMake] Don't LTO optimize targets that aren't part of any distribution

When using distributions, targets that aren't included in any
distribution don't need to be as optimized as targets that are
included since those targets are typically only used for tests.

We might consider avoiding LTO for these targets altogether, see
https://lists.llvm.org/pipermail/llvm-dev/2021-April/149843.html

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

[mlir][docs] Fix minor typos in vector dialect docs

Updates a minor typo in vector dialect documentation.

Reviewed By: aartbik

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

Revert "[Driver] Delete -mimplicit-it="

This reverts commit 2919222d8017f2425a85765b95e4b7c6f8e70ca4.

That commit broke backwards compatibility. Additionally, the
replacement, -Wa,-mimplicit-it, isn't yet supported by any stable
release of Clang.

See D102812 for a fix for the error cases when callers specify both
-mimplicit-it and -Wa,-mimplicit-it.

[NFC][tsan] clang-format the test

[mlir][sparse] skip sparsification for unannotated (or unhandled) cases

Skip the sparsification pass for Linalg ops without annotated tensors
(or cases that are not properly handled yet).

Reviewed By: bixia

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

[mlir] Properly align StorageUniquer::BaseStorage to fix 32 bit build

We allow stealing up to 3 bits of pointers to BaseStorage, so we need to make sure that we align by at least 8.

[mlir] Harmonize TOSA include guards

Reviewed By: sjarus

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

[mlir][CAPI] Expose [u]int8 DenseElementsAttr.

Also, fix a small typo where the "unsigned" splat variants were not
being created with an unsigned type.

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

[CSSPGO] Avoid deleting probe instruction in FoldValueComparisonIntoPredecessors

This change tries to fix a place missing `moveAndDanglePseudoProbes `. In FoldValueComparisonIntoPredecessors, it folds the BB into predecessors and then marked the BB unreachable. However, the original logic from the BB is still alive, deleting the probe will mislead the SampleLoader mark it as zero count sample.

Reviewed By: hoy, wenlei

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

Treat implicit deduction guides as being equivalent to their
corresponding constructor for access checking purposes.

[ORC-RT] Add ORC runtime error and expected types.

These will be used for error propagation and handling in the ORC runtime.

The implementations of these types are cut-down versions of the error
support in llvm/Support/Error.h. Most advice on llvm::Error and llvm::Expected
(e.g. from the LLVM Programmer's manual) applies equally to __orc_rt::Error
and __orc_rt::Expected. The primary difference is the mechanism for testing
and handling error types: The ORC runtime uses a new 'error_cast' operation
to replace the handleErrors family of functions. See error_cast comments in
error.h.

[ORC] Add a CPU getter to JITTargetMachineBuilder.

Revert "[lldb] Fix UB in half2float and add some more tests."

This reverts commit 4b074b49be206306330076b9fa40632ef1960823.

Some of the new tests are failing on Debian.

[mlir] Add include guard to TOSA tblgen passes

Reviewed By: sjarus, stellaraccident

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

[Reland] [mlir] Speed up Lexer::getEncodedSourceLocation

Reland Note: This was accidentally reverted in 80d981eda69f1ada6d944ed89571456cad13b850, but is an important improvement even outside of the driving motivator in D102567.

We currently use SourceMgr::getLineAndColumn to get the line and column for an SMLoc, but this includes a call to StringRef::find_last_of that ends up dominating compile time. In D102567, we start creating locations from the input file for block arguments which resulted in an extreme performance regression for modules with very large amounts of block arguments. This revision switches to just using a pointer offset from the beginning of the line to calculate the column(all MLIR files are simple ascii), resulting in a compile time reduction from 4700 seconds (1 hour and 18 minutes) to 8 seconds.

[OpaquePtr] Make atomicrmw work with opaque pointers

FullTy is only necessary when we need to figure out what type an
instruction works with given a pointer's pointee type. However, we just
end up using the value operand's type, so FullTy isn't necessary.

Reviewed By: dblaikie

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

[OpaquePtr] Make cmpxchg work with opaque pointers

Reviewed By: dblaikie

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

[PDB] Do not record PGO or coverage public symbols

These symbols are long, and they tend to cause the PDB file size to
overflow. They are generally not necessary when debugging problems in
user code.

This change reduces the size of chrome.dll.pdb with coverage from
6,937,108,480 bytes to 4,690,210,816 bytes.

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

[OpaquePtr] Make GEPs work with opaque pointers

No verifier changes needed, the verifier currently doesn't check that
the pointer operand's pointee type matches the GEP type. There is a
similar check in GetElementPtrInst::Create() though.

Reviewed By: dblaikie

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

[lldb] Fix UB in half2float and add some more tests.

The added DumpDataExtractorTest uncovered that this is lshifting a negative
integer which upsets ubsan and breaks the sanitizer bot. This patch just
changes the variable we shift to be unsigned and adds a bunch of tests to make
sure this function does what it promises.

[clang][ObjC] Allow different availability annotation on a method
when implementing an optional protocol requirement

When an Objective-C method implements an optional protocol requirement,
allow the method to use a newer introduced or older obsoleted
availability version than what's specified on the method in the protocol
itself. This allows SDK adopters to adopt an optional method from a
protocol later than when the method is introduced in the protocol. The users
that call an optional method on an object that conforms to this protocol
are supposed to check whether the object implements the method or not,
so a lack of appropriate `if (@available)` check for a new OS version
is not a cause of concern as there's already another runtime check that's required.

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

[Diagnostics] Allow emitting analysis and missed remarks on functions

Summary:
Currently, only `OptimizationRemarks` can be emitted using a Function.
Add constructors to allow this for `OptimizationRemarksAnalysis` and
`OptimizationRemarkMissed` as well.

Reviewed By: jdoerfert thegameg

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

[x86] add tests for fma folds with fast-math-flags; NFC

Part of prep work for D90901

[x86] propagate FMF from x86-specific intrinsic nodes to others during combining

This is another FMF gap exposed by D90901, but I don't see a way
to show the difference in a regression test as with:
f66ba4c
6025663

We will see an asm difference if we add a test as part of D90901.

[lld/mac] Remove dead declaration

[libcxx][ranges] adds concept `sized_range` and cleans up `ranges::size`

* adds `sized_range` and conformance tests
* moves `disable_sized_range` into namespace `std::ranges`
* removes explicit type parameter

Implements part of P0896 'The One Ranges Proposal'.

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

[MCA] Unbreak the buildbots by passing flag -mcpu=generic to the new test added by commit e5d59db469.

This should unbreak buildbot clang-ppc64le-linux-lnt.

[libcxx][iterator][nfc] acquires lock for working on [range.iter.ops]

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

[x86] update fma test with deprecated intrinsics; NFC

Similar to 8854b27 -

All of the CHECK lines should be identical to before,
but without any of the x86-specific calls that were
replaced with generic FMA long ago.

The file still has value because it shows a miscompile
as demonstrated in D90901, but we probably need to
add tests with FMF to make that explicit without
losing coverage.

[MLIR] Update Vector To LLVM conversion to be aware of assume_alignment

vector.transfer_read and vector.transfer_write operations are converted
to llvm intrinsics with specific alignment information, however there
doesn't seem to be a way in llvm to take information from llvm.assume
intrinsics and change this alignment information.  In any
event, due the to the structure of the llvm.assume instrinsic, applying
this information at the llvm level is more cumbersome.  Instead, let's
generate the masked vector load and store instrinsic with the right
alignment information from MLIR in the first place.  Since
we're bothering to do this, lets just emit the proper alignment for
loads, stores, scatter, and gather ops too.

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

[CoverageMapping] Handle gaps in counter IDs for source-based coverage

For source-based coverage, the frontend sets the counter IDs and the
constraints of counter IDs is not defined.  For e.g., the Rust frontend
until recently had a reserved counter #0
(https://github.com/rust-lang/rust/pull/83774).  Rust coverage
instrumentation also creates counters on edges in addition to basic
blocks.  Some functions may have more counters than regions.

This breaks an assumption in CoverageMapping.cpp where the number of
counters in a function is assumed to be bounded by the number of
regions:
  Counts.assign(Record.MappingRegions.size(), 0);

This assumption causes CounterMappingContext::evaluate() to fail since
there are not enough counter values created in the above call to
`Counts.assign`.  Consequently, some uncovered functions are not
reported in coverage reports.

This change walks a Function's CoverageMappingRecord to find the maximum
counter ID, and uses it to initialize the counter array when instrprof
records are missing for a function in sparse profiles.

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

[NFCI][Local] TryToSimplifyUncondBranchFromEmptyBlock(): use DeleteDeadBlocks()

[NFCI][Local] MergeBlockIntoPredecessor(): use DeleteDeadBlocks()

[NFCI][Local] removeUnreachableBlocks(): use DeleteDeadBlocks()

[MCA] llvm-mca MCTargetStreamer segfault fix

In order to create the code regions for llvm-mca to analyze, llvm-mca creates an
AsmCodeRegionGenerator and calls AsmCodeRegionGenerator::parseCodeRegions().
Within this function, both an MCAsmParser and MCTargetAsmParser are created so
that MCAsmParser::Run() can be used to create the code regions for us.

These parser classes were created for llvm-mc so they are designed to emit code
with an MCStreamer and MCTargetStreamer that are expected to be setup and passed
into the MCAsmParser constructor. Because llvm-mca doesn’t want to emit any
code, an MCStreamerWrapper class gets created instead and passed into the
MCAsmParser constructor. This wrapper inherits from MCStreamer and overrides
many of the emit methods to just do nothing. The exception is the
emitInstruction() method which calls Regions.addInstruction(Inst).

This works well and allows llvm-mca to utilize llvm-mc’s MCAsmParser to build
our code regions, however there are a few directives which rely on the
MCTargetStreamer. llvm-mc assumes that the MCStreamer that gets passed into the
MCAsmParser’s constructor has a valid pointer to an MCTargetStreamer. Because
llvm-mca doesn’t setup an MCTargetStreamer, when the parser encounters one of
those directives, a segfault will occur.

In x86, each one of these 7 directives will cause this segfault if they exist in
the input assembly to llvm-mca:

.cv_fpo_proc
.cv_fpo_setframe
.cv_fpo_pushreg
.cv_fpo_stackalloc
.cv_fpo_stackalign
.cv_fpo_endprologue
.cv_fpo_endproc
I haven’t looked at other targets, but I wouldn’t be surprised if some of the
other ones also have certain directives which could result in this same
segfault.

My proposed solution is to simply initialize an MCTargetStreamer after we
initialize the MCStreamerWrapper. The MCTargetStreamer requires an ostream
object, but we don’t actually want any of these directives to be emitted
anywhere, so I use an ostream created with the nulls() function. Since this
needs to happen after the MCStreamerWrapper has been initialized, it needs to
happen within the AsmCodeRegionGenerator::parseCodeRegions() function. The
MCTargetStreamer also needs an MCInstPrinter which is easiest to initialize
within the main() function of llvm-mca. So this MCInstPrinter gets constructed
within main() then passed into the parseCodeRegions() function as a parameter.
(If you feel like it would be appropriate and possible to create the
MCInstPrinter within the parseCodeRegions() function, then feel free to modify
my solution. That would stop us from having to pass it into the function and
would limit its scope / lifetime.)

My solution stops the segfault from happening and still passes all of the
current (expected) llvm-mca tests. I also added a new test for x86 that checks
for this segfault on an input that includes one of the .cv_fpo directives (this
test fails without my solution, but passes with it).

As far as I can tell, all of the functions that I modified are only called from
within llvm-mca so there shouldn’t be any worries about breaking other tools.

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

Do actual DCE in LoopUnroll (try 4)

Turns out simplifyLoopIVs sometimes returns a non-dead instruction in it's DeadInsts out param.  I had done a bit of NFC cleanup which was only NFC if simplifyLoopIVs obeyed it's documentation.  I'm simplfy dropping that part of the change.

Commit message from try 3:

Recommitting after fixing a bug found post commit. Amusingly, try 1 had been correct, and by reverting to incorporate last minute review feedback, I introduce the bug. Oops. :)

Original commit message:

The problem was that recursively deleting an instruction can delete instructions beyond the current iterator (via a dead phi), thus invalidating iteration. Test case added in LoopUnroll/dce.ll to cover this case.

LoopUnroll does a limited DCE pass after unrolling, but if you have a chain of dead instructions, it only deletes the last one. Improve the code to recursively delete all trivially dead instructions.

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

Revert "Reapply "[clang][deps] Support inferred modules""

This reverts commit c98833cdaad01787ea70ecdfabb05a7e142a6671.
The test `ClangScanDeps/modules-inferred-explicit-build.m` creates files
in the current directory.

[x86] propagate FMF from x86-specific intrinsic nodes to others during lowering

This is another fast-math-flags failure exposed by D90901.

[x86] add test check lines to demonstrate FMF propagation failure; NFC

[ScalarEvolution] Remove unused ExitLimit::hasOperand() method (NFC)

We only use BackedgeTakenInfo::hasOperand().

[profile] Skip mmap() if there are no counters

If there are no counters, an mmap() of the counters section would fail
due to the size argument being too small (EINVAL).

rdar://78175925

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

Recommit "[GlobalISel] Simplify G_ICMP to true/false when the result is known"

Add missing REQUIRES line to
prelegalizer-combiner-icmp-to-true-false-known-bits.

[CSSPGO] Overwrite branch weight annotated in previous pass.

Sample profile loader can be run in both LTO prelink and postlink. Currently the counts annoation in postilnk doesn't fully overwrite what's done in prelink. I'm adding a switch (`-overwrite-existing-weights=1`) to enable a full overwrite, which includes:

1. Clear old metadata for calls when their parent block has a zero count. This could be caused by prelink code duplication.

2. Clear indirect call metadata if somehow all the rest targets have a sum of zero count.

3. Overwrite branch weight for basic blocks.

With a CS profile, I was seeing #1 and #2 help reduce code size by preventing post-sample ICP and CGSCC inliner working on obsolete metadata, which come from a partial global inlining in prelink.  It's not expected to work well for non-CS case with a less-accurate post-inline count quality.

It's worth calling out that some prelink optimizations can damage counts quality in an irreversible way. One example is the loop rotate optimization. Due to lack of exact loop entry count (profiling can only give loop iteration count and loop exit count), moving one iteration out of the loop body leaves the rest iteration count unknown. We had to turn off prelink loop rotate to achieve a better postlink counts quality. A even better postlink counts quality can be archived by turning off prelink CGSCC inlining which is not context-sensitive.

Reviewed By: wenlei, wmi

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

Revert "Do actual DCE in LoopUnroll (try 3)"

This reverts commit b6320eeb8622f05e4a5d4c7f5420523357490fca
as it causes clang to assert; see
https://reviews.llvm.org/rGb6320eeb8622f05e4a5d4c7f5420523357490fca.

[mlir][SCF] NFC - Drop SCF EDSC usage

Drop the SCF dialect EDSC subdirectory and update all uses.

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

Fix lld macho standalone build by including llvm/Config/llvm-config.h instead of llvm/Config/config.h

lld/MachO/Driver.cpp and lld/MachO/SyntheticSections.cpp include
llvm/Config/config.h which doesn't exist when building standalone lld.

This patch replaces llvm/Config/config.h include with llvm/Config/llvm-config.h
just like it is in lld/ELF/Driver.cpp and HAVE_LIBXAR with LLVM_HAVE_LIXAR and
moves LLVM_HAVE_LIBXAR from config.h to llvm-config.h

Also it adds LLVM_HAVE_LIBXAR to LLVMConfig.cmake and links liblldMachO2.so
with XAR_LIB if LLVM_HAVE_LIBXAR is set.

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

[VP] make getFunctionalOpcode return an Optional

The operation of some VP intrinsics do/will not map to regular
instruction opcodes.  Returning 'None' seems more intuitive here than
'Instruction::Call'.

Reviewed By: frasercrmck

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

[AsmParser][SystemZ][z/OS] Introducing HLASM Parser support to AsmParser - Part 1

- This patch (is one in a series of patches) which introduces HLASM Parser support (for the first parameter of inline asm statements) to LLVM ([[ https://lists.llvm.org/pipermail/llvm-dev/2021-January/147686.html | main RFC here ]])
- This patch in particular introduces HLASM Parser support for Z machine instructions.
- The approach taken here was to subclass `AsmParser`, and make various functions and variables as "protected" wherever appropriate.
- The `HLASMAsmParser` class overrides the `parseStatement` function. Two new private functions `parseAsHLASMLabel` and `parseAsMachineInstruction` are introduced as well.

The general syntax is laid out as follows (more information available in [[ https://www.ibm.com/support/knowledgecenter/SSENW6_1.6.0/com.ibm.hlasm.v1r6.asm/asmr1023.pdf | HLASM V1R6 Language Reference Manual ]] - Chapter 2 - Instruction Statement Format):

```
<TokA><spaces.*><TokB><spaces.*><TokC><spaces.*><TokD>
```

1. TokA is referred to as the Name Entry. This token is optional
2. TokB is referred to as the Operation Entry. This token is mandatory.
3. TokC is referred to as the Operand Entry. This token is mandatory
4. TokD is referred to as the Remarks Entry. This token is optional

- If TokA is provided, then we either parse TokA as a possible comment or as a label (Name Entry), Tok B as the Operation Entry and so on.
- If TokA is not provided (i.e. we have one or more spaces and then the first token), then we will parse the first token (i.e TokB) as a possible Z machine instruction, TokC as the operands to the Z machine instruction and TokD as a possible Remark field
- TokC (Operand Entry), no spaces are allowed between OperandEntries. If a space occurs it is classified as an error.
- TokD if provided is taken as is, and emitted as a comment.

The following additional approach was examined, but not taken:

- Adding custom private only functions to base AsmParser class, and only invoking them for z/OS. While this would eliminate the need for another child class, these private functions would be of non-use to every other target. Similarly, adding any pure virtual functions to the base MCAsmParser class and overriding them in AsmParser would also have the same disadvantage.

Testing:

- This patch doesn't have tests added with it, for the sole reason that MCStreamer Support and Object File support hasn't been added for the z/OS target (yet). Hence, it's not possible generate code outright for the z/OS target. They are in the process of being committed / process of being worked on.

- Any comments / feedback on how to combat this "lack of testing" due to other missing required features is appreciated.

Reviewed By: Kai, uweigand

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

[lldb] Enable TestCppBitfields on Windows

The test works correctly on Windows, the linked bug has been resolved.

Reviewed By: teemperor

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

[clang][patch] Add support for option -fextend-arguments={32,64}: widen integer arguments to int64 in unprototyped function calls

Reviewed By: Aaron Ballman

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

Reapply "[X86] Limit X86InterleavedAccessGroup to handle the same type case only"

The current implementation assumes the destination type of shuffle is the same as the decomposed ones. Add the check to avoid crush when the condition is not satisfied.

This fixes PR37616.

Reviewed By: RKSimon

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

Revert rG528bc10e95d5f9d6a338f9bab5e91d7265d1cf05 : "[X86FixupLEAs] Transform the sequence LEA/SUB to SUB/SUB"

Reports on D101970 indicate this is causing failures on multi-stage compiles.

[lldb] 2/2: Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC)

DW_AT_ranges can use DW_FORM_sec_offset (instead of DW_FORM_rnglistx).
In such case DW_AT_rnglists_base does not need to be present.
DWARF-5 spec:
        "If the offset_entry_count is zero, then DW_FORM_rnglistx cannot
        be used to access a range list; DW_FORM_sec_offset must be used
        instead. If the offset_entry_count is non-zero, then
        DW_FORM_rnglistx may be used to access a range list;"

This fix is for TestTypeCompletion.py category `dwarf` using GCC with DWARF-5.

The fix just provides GetRnglist() lazy getter for `m_rnglist_table`.
The testcase is easier to review by:
        diff -u lldb/test/Shell/SymbolFile/DWARF/DW_AT_low_pc-addrx.s \
          lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s

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

[nfc] [lldb] 1/2: Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC)

Refactor code only for D98289.

Reviewed By: clayborg

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

[X86][AVX] createVariablePermute - generalize the PR50356 fix for smaller indices vector as well

Generalize the fix from rGd0902a8665b1 by ensuring we widen/narrow the indices subvector first and then perform the ZERO_EXTEND_VECTOR_INREG (if necessary), which should allow us to perform the variable permutes with source/destination/indices vectors of any widths.

[X86][Atom] Fix vector integer shift by immediate resource/throughputs

Match whats documented in the Intel AOM (and Agner/instlatx64 agree) - these are all Port0 only.

Now that we can use in-order models in llvm-mca, the atom model is a good "worst case scenario" analysis for x86.

[mir][Python][linalg] Support OpDSL extensions in C++.

The patch extends the yaml code generation to support the following new OpDSL constructs:
- captures
- constants
- iteration index accesses
- predefined types
These changes have been introduced by revision
https://reviews.llvm.org/D101364.

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

[lldb] Encode `bool` as unsigned int

`bool` is considered to be unsigned according to `std::is_unsigned<bool>::value` (and `Type::GetTypeInfo`). Encoding it as signed int works fine for normal variables and fields, but breaks when reading the values of boolean bitfields. If the field is declared as `bool b : 1` and has a value of `0b1`, the call to `SBValue::GetValueAsSigned()` will return `-1`.

Reviewed By: teemperor

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

[lldb][NFC] Remove sample test boilerplate from TestBreakOnCPP11Initializers

Revert "[GlobalISel] Simplify G_ICMP to true/false when the result is known"

This reverts commit 892497c806306a4b7185ead16d60b0ebcca0a304.
Breaks tests, see comments on https://reviews.llvm.org/D102542

[llvm][AArch64][SVE] Model FFR-using intrinsics with inaccessiblemem

Intriniscs reading or writing the FFR register need to model the fact
there is additional state being read/wrtten.

Model this state as inaccessible memory.

* setffr => write inaccessiblememonly
* rdffr => read inaccessiblememonly
* ldff* => read arg memory, write inaccessiblemem
* ldnf => read arg memory, write inaccessiblemem

[mlir][Vector] NFC - Drop vector EDSC usage

Drop the vector dialect EDSC subdirectory and update all uses.

Revert "[X86] Limit X86InterleavedAccessGroup to handle the same type case only"

This reverts commit ca23a38e373142a18ab56700ba4f3b947bfe9db0.

Revert due to EXPENSIVE_CHECKS fail.

Remove scalable vector assert from InnerLoopVectorizer::setDebugLocFromInst

In InnerLoopVectorizer::setDebugLocFromInst we were previously
asserting that the VF is not scalable. This is because we want to
use the number of elements to create a duplication factor for the
debug profiling data. However, for scalable vectors we only know the
minimum number of elements. I've simply removed the assert for now
and added a FIXME saying that we assume vscale is always 1. When
vscale is not 1 it just means that the profiling data isn't as
accurate, but shouldn't cause any functional problems.

[ARM][NEON] Combine base address updates for vst1x intrinsics

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

[SDAG] propagate FMF from target-specific IR intrinsics

This is a step towards relying more on node-level FMF rather than function-wide
or target settings.
I think it was just an oversight that we didn't get this path in D87361
or follow-on patches.

The lack of FMF propagation is blocking D90901 from converting tests to IR-level FMF.

We can't do much more than this currently because we also fail to propagate flags
from x86-specific node to generic FMA node. That would be another patch, so the
test just verifies that we can transfer from IR to initial SDAG node.

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

Reapply "[clang][deps] Support inferred modules"

This reapplies commit 95033eb3 that reverted commit 1d9e8e13.

The tests were failing on Windows due to spaces and backslashes in paths not being handled carefully.

[clang] Fix a crash on CheckArgAlignment.

We might encounter an undeduced type before calling getTypeAlignInChars.

NOTE: this retrieves the fix from
8f80c66bd2982788a8eede4419684ca72f48b9a2, which was removed in Adam's
followup fix fbfcfdbf6828b8d36f4ec0ff5f4eac11fb1411a5. We originally
thought the crash was caused by recovery-ast, but it turns out it can
occur for other cases, e.g. typo-correction.

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

[X86] Atom (pre-SLM) doesn't support PTEST instructions

[X86] Remove copy + paste typos in AtomWriteResPair comment.

Remnants from when the Atom model was copied from the Btver2 model.....

[HIP] Tighten checks in hip-include-path.hip test case

The checks (both positive and negative checks) in the test case
hip-include-path.hip could mistakenly end up matching the string
"clang" from the InstalledDir in case the build dir for example
was named "/home/username/build-clang/". Intention with this
patch is to tighten up the checks a bit to filter our the
part of the paths that match with InstalledDir when doing the
checks, as well as matching "/lib/clang/" rather than
just "clang/".

Problem was found when building with
  -DCLANG_DEFAULT_RTLIB=compiler-rt
  -DCLANG_DEFAULT_CXX_STDLIB=libc++
and having "clang/" in the path to the build dir.

Reviewed By: yaxunl

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

[NFCI][SimplifyCFG] removeEmptyCleanup(): use DeleteDeadBlock()

This required some changes to, instead of eagerly making PHI's
in the UnwindDest valid as-if the BB is already not a predecessor,
to be valid while BB is still a predecessor.

[NFCI][SimplifyCFG] removeEmptyCleanup(): streamline PHI node updating

[NFC][SimplifyCFG] removeEmptyCleanup(): use BasicBlock::phis()

tsan: mark sigwait as blocking

Add a test case reported in:
https://github.com/google/sanitizers/issues/1401
and fix it.
The code assumes sigwait will process other signals.

Reviewed By: vitalybuka

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

[x86] Fix FMF propagation test

[analyzer] Check the checker name, rather than the ProgramPointTag when silencing a checker

The program point created by the checker, even if it is an error node,
might not be the same as the name under which the report is emitted.
Make sure we're checking the name of the checker, because thats what
we're silencing after all.

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

[X86] Limit X86InterleavedAccessGroup to handle the same type case only

The current implementation assumes the destination type of shuffle is the same as the decomposed ones. Add the check to avoid crush when the condition is not satisfied.

This fixes PR37616.

Reviewed By: RKSimon

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

Use a non-recursive mutex in GsymCreator.

There doesn't seem to be a need to support recursive locking,
and a recursive mutex is unnecessarily inefficient.

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

Move FunctionInfo in addFunctionInfo rather than copying.

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

Avoid calculating the string hash twice in GsymCreator::insertString.

Do the single hash calculation before acquiring the lock, to reduce
lock contention. If Copy is true, and the string was not yet contained
in the StringStorage, use the new address from StringStorage, but
reuse the hash we already calculated.

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

Reformat GSYMCreator.cpp

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

MachineBasicBlock: add liveout iterator aware of which liveins are defined by the runtime.

Using this in RegAlloc fast reduces register pressure, and in some cases allows
x86 code to compile that wouldn't before.

[LV] Add -scalable-vectorization=<option> flag.

This patch adds a new option to the LoopVectorizer to control how
scalable vectors can be used.

Initially, this suggests three levels to control scalable
vectorization, although other more aggressive options can be added in
the future.

The possible options are:
- Disabled:   Disables vectorization with scalable vectors.
- Enabled:    Vectorize loops using scalable vectors or fixed-width
              vectors, but favors fixed-width vectors when the cost
              is a tie.
- Preferred:  Like 'Enabled', but favoring scalable vectors when the
              cost-model is inconclusive.

Reviewed By: paulwalker-arm, vkmr

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

[NFCI][SimplifyCFG] simplifyUnreachable(): use DeleteDeadBlock()

[NFCI][SimplifyCFG] simplifyReturn(): use DeleteDeadBlock()

[NFCI][SimplifyCFG] simplifySingleResume(): use DeleteDeadBlock()

[NFCI][SimplifyCFG] simplifyCommonResume(): use DeleteDeadBlock()

[llvm-objcopy] Add support for '--' for delimiting options from input/output files

This will allow to use llvm-objcopy with file names that begin with dashes.

Reviewed By: jhenderson

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

[RISCV] Support INSERT_VECTOR_ELT into i1 vectors

Like the element extraction of these vectors, we choose to promote up to
an i8 vector type and perform the insertion there.

Reviewed By: craig.topper

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

[NFCI] SimplifyCFGPass: mergeEmptyReturnBlocks(): use DeleteDeadBlocks()

In this case, it does the same thing as the original pattern does.

SimplifyCFG has a few lurking miscompilations about deleting blocks that
have their address taken, and consistently using DeleteDeadBlocks() instead
 of a hand-rolled pattern will allow to weed those cases out easierly.

[clang-tidy] Fix a crash on invalid code for memset-usage check.

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

Fix sanitizer test errors from commit 886629a8

Explictly handle the empty string in the Hash calculation.

[mlir] Use VectorTransferPermutationMapLoweringPatterns in VectorToSCF

VectorTransferPermutationMapLoweringPatterns can be enabled via a pass option. These additional patterns lower permutation maps to minor identity maps with broadcasting, if possible, allowing for more efficient vector load/stores. The option is deactivated by default.

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

[libfuzzer] Update doc mentioning removed flags.

[mlir][Linalg] Break unnecessary dependency through unused `outs` tensor.

LinalgOps that are all parallel do not use the value of `outs`
tensor. The semantics is that the `outs` tensor is fully
overwritten. Using anything other than `init_tensor` can add false
dependencies between operations, when the use is just for the shape of
the tensor. Adding a canonicalization to always use `init_tensor` in
such cases, breaks this dependence.

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

[NewPM] Add options to PrintPassInstrumentation

To bring D99599's implementation in line with the existing
PrintPassInstrumentation, and to fix a FIXME, add more customizability
to PrintPassInstrumentation.

Introduce three new options. The first takes over the existing
"-debug-pass-manager-verbose" cl::opt.

The second and third option are specific to -fdebug-pass-structure. They
allow indentation, and also don't print analysis queries.

To avoid more golden file tests than necessary, prune down the
-fdebug-pass-structure tests.

Reviewed By: asbirlea

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