This patch enables extending loads for fixed length SVE code generation.

There is a slight regression here in the mulh tests; since these tests
load the parameter and then extend it these are treated as extending
loads which are merged, preventing the mulh instruction from being
generated. As this affects scalable SVE codegen as well this should be
addressed in a separate patch.

Reviewed By: bsmith

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

The patch in http://reviews.llvm.org/D106431 landed in commit
4a097efe to the main branch.
However, this patch was also backported to upcoming release 13.0.0 in
commit 8dcdfc0de84f60b5b4af97ac5b357881af55bc6e, which makes this entry
in the release notes **NOT** a new thing for the purposes of 14.0.0.

After
https://github.com/llvm/llvm-project/commit/9da70ab3d43c79116f80fc06aa7cf517374ce42c
we saw a few regressions around trailing attribute definitions and in
typedefs (examples in the added test cases). There's some tension
distinguishing K&R definitions from attributes at the parser level,
where we have to decide if we need to put the type of the K&R definition
on a new unwrapped line before we have access to the rest of the line,
so we're scanning backwards and looking for a pattern like f(a, b). But
this type of pattern could also be an attribute macro, or the whole
declaration could be a typedef itself. I updated the code to check for a
typedef at the beginning of the line and to not consider raw identifiers
as possible first K&R declaration (but treated as an attribute macro
instead). This is not 100% correct heuristic, but I think it should be
reasonably good in practice, where we'll:
  * likely be in some very C-ish code when using K&R style (e.g., stuff
    that uses `struct name a;` instead of `name a;`
  * likely be in some very C++-ish code when using attributes
  * unlikely mix up the two in the same declaration.

Ideally, we should only decide to add the unwrapped line before the K&R
declaration after we've scanned the rest of the line an noticed the
variable declarations and the semicolon, but the way the parser is
organized I don't see a good way to do this in the current parser, which
only has good context for the previously visited tokens. I also tried
not emitting an unwrapped line there and trying to resolve the situation
later in the token annotator and the continuation indenter, and that
approach seems promising, but I couldn't make it to work without
messing up a bunch of other cases in unit tests.

Reviewed By: MyDeveloperDay

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

Reviewed By: pengfei

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

Previously I xfailed this but it's only failing in stage 2 so
we get xpasses for stage 1. Disable it completely.

The register classes are generated by TableGen, use them instead of
handwritten tables.

Reviewed By: david-arm

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

A follow-up to
https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62
where we handle the case where the semicolon is followed by a trailing
comment.

Reviewed By: MyDeveloperDay

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

AppMemBeg was renamed to LoAppMemBeg in 3830c934
("tsan: rename kAppMemBeg to kLoAppMemBeg").
Rename remaining uses of the old name in tsan_platform_mac.cpp.

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

Alpine enables PIE by default.

Follow up on https://reviews.llvm.org/D105741

- Add new test that exhaustively checks the output file's content
- Fix typos in documentation and other minor fixes

Reviewed By: wallace

Original Author: jj10306

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

Originally committed as ffc3fb66
Reverted in fcf2d5f4 due to an
assertion failure.

Original commit message:

Allow the folding even if there is an
intervening bitcast.

Reviewed By: arsenm

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

These two tests, TestSkinnyCorefile.py and TestStackCorefile.py,
require a new debugserver on darwin systems to run correctly; for now,
skip them if the system debugserver is in use.  There's no easy way to
test if the debugserver being used supports either of these memory
region info features. For end users, the fallback will be a full
corefile and that's not the worst thing, but for the tests it is a
problem.

These rules were originally written when the new predicate based legalizer
was introduced in an attempt to preserve existing behaviour. It wasn't
properly kept up to date as things like vector support was split out into
G_CONCAT_VECTORS, and frankly, even if it was, it was too complex.

It's much easier to start from scratch with what we can actually support,
which is just a few type combinations. Anything illegal we should either
legalize, or should be eliminated as a side effect of artifact combination.

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

This change adds the stroll function, but most of the implementation is
in the new file str_conv_utils.h since many of the other integer
conversion functions are implemented through what are effectively calls
to strtoll.

Reviewed By: sivachandra

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

This can be useful when one needs to know which unrolled iteration an Op belongs to, for example, conveying noalias information among memory-affecting ops in parallel-access loops.

Reviewed By: mehdi_amini

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

Currently we use a centralized string map(StringMap<FunctionSamples> ProfileMap) to store the profile while populating the sample, which might cause the memory usage bottleneck. I saw in an extreme case, there are thousands of samples whose context stack depth is >= 100. The memory consumption can be greater than 100GB.

As here the context is used for inlining, we can assume we won't have so many of inlinees keeping inlined at the same root function, so this change tried to cap the context stack and merge the samples for peak memory reduction and this is done after recursion compression.

The default value is -1 meaning no depth limit, in the future we can tune to a smaller one.

Reviewed By: hoy, wenlei

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

No longer needed after c1ebefdf

BOOL is bool instead of signed char on ARM. See
https://reviews.llvm.org/D93421#inline-874116 for details.

The assertion can fail in some cases when an i16 constant is promoted
to i32.

e.g. in the added test case the value `i16 -32768` is within the range
of i16 but the assert fails when the constant is promoted to positive
`i32 32768` by an earlier call to DAG.getConstant().

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

Change-Id: I2f6179783cbc9630e6acab149a762b43c65664de

The benefit of using assertIn is an improved error message when the
assertion fails:

  AssertionError: False is not True

becomes

  AssertionError: 'have ints 5 20 20 5' not found in '""'

All TestConcurrent.* tests that involve watchpoints are broken on
ARM-based Darwin platforms, including Apple Silicon.

rdar://81811539

This is a workaround until https://reviews.llvm.org/D81892 is merged
and the internal Lit shell stops conflating error output with normal
output. Without this, any program that writes to stderr will trip up
the programOutput function, because it will pick up the '# command stderr:'
string and think it's part of the command's stdout.

rdar://81056048

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

All supported compilers implement __builtin_addressof. Even MSVC implements
addressof as a simple call to __builtin_addressof, so it would work if we
were to port libc++ to that compiler.

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

release call

findSafeStoreForStoreStrongContraction checks whether it's safe to move
the release call to the store by inspecting all instructions between the
two, but was ignoring retain instructions. This was causing objects to
be released and deallocated before they were retained.

rdar://81668577

Include macosx in the list of operating systems for which this is broken
on arm64.

rdar://34027183

Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack.  Keep track of
memory regions that are stack memory in lldb.  Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.

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

c1ebefdf "[mlir] Make polynomial approximation emit
std instead of LLVM ops" removed the dependence on LLVMDialect.

Remove the dependence also from BUILD.bazel.

Reviewed By: bkramer

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

A repeated null value at the end of an input record with a count > 1
would incorrectly advance to the next record when resumed.  Fix.

Improve some poor naming and code flow noticed while debugging, so
next time will be easier.

Extend a unit test to check this case.

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

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

We do not want to define __PRIVILEGED__. There is no use case for the
definition and gcc does not define it. This patch removes that definition.

Reviewed By: lei, NeHuang

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

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

As of https://reviews.llvm.org/D104431, the test suite runs
llvm-profdata, so it must be added to the list of deps.

We can hoist the check for the dllexport attribute to before the check
if this is a static data member or method.

    experimental.vector.reverse(splat(X)) -> splat(X)

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

Change-Id: Id29ba88fd669ff8686712e96b1bdc46dda5b853c