This helps to avoid ambiguity when the address contains only digits 0..9.

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

For now, the source variable locations are printed at about the same
space as the comments for disassembled code, which can make some ranges
for variables disappear if a line contains comments, for example:

                                        ┠─ bar = W1
0:  add x0, x2, #2, lsl #12     // =8192┃
4:  add z31.d, z31.d, #65280    // =0xff00
8:  nop                                 ┻

The patch shifts the report a bit to allow printing comments up to
approximately 16 characters without interferences.

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

LLVM disassembler can generate comments for disassembled instructions.
The patch enables printing these comments for 'llvm-objdump -d'.

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

This reverts commit 8f43407a due to
failure on its associated test.

This reverts commit af03f7fb.

Looks like the test is passing in some architectures. Reverting to green.

We can exploit branches by `undef` condition. Frankly, the LangRef says that
such branches are UB, so we can assume that all outgoing edges of such blocks
are dead.

However, from practical perspective, we know that this is not supported correctly
in some other places. So we are being conservative about it.

Branch by undef is treated in the following way:
- If it is a loop-exiting branch, we always assume it exits the loop;
- If not, we arbitrarily assume it takes `true` value.

Differential Revision: https://reviews.llvm.org/D104689
Reviewed By: nikic

Prototype
```
unsigned int __fetch_and_add (volatile unsigned int* addr, unsigned int
val);
unsigned long __fetch_and_addlp (volatile unsigned long* addr, unsigned
long val);
```
Ref:
https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-fetch

Reviewed By: #powerpc, w2yehia, lkail

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

cli-wrapper-mpxtable.cpp was emitting warnings from printfs of
uint64_t on 32 bit arm build. This patch makes affected printfs
in cli-wrapper-mpxtable.cpp portable accross targets variants.

This test is again failing across multiple bots and passing on others
there is no reliable way to enable it for some of the bots while
disabling for the unsupported ones. Tagging it as unsupported across all
types of Arm 32 bit cores.

Implementation of formal arguments lowering in the IRTranslator for the
M68k backend

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

This test has started passing consistently on 32bit arm where underlying
core is reported as Armv7 or Thumbv7.
However it still fails intermittently on 32bit AArch32 reported as Armv8l.

https://lab.llvm.org/buildbot/#/builders/190/builds/20
https://lab.llvm.org/buildbot/#/builders/170/builds/41

PR37255: DebugInfo: LTO with -g inlined into -gmlt combined with Split DWARF without CU cross-references

A combination of features ^ that lead to a mismatch of expectations
about how a subprogram definition DIE would be produced with/without a
declaration when taking full -g debug info and inlining it into a -gmlt
CU - specifically when using Split DWARF that doesn't support cross-CU
references, so we have to put the -g debug info into the -gmlt CU, which
gets confusing about which mode is respected.

This patch comes down on respecting the CU the debug info is emitted
into, rather than preserving the full debug info when it's emitted into
the gmlt CU.

We use (and (ctpop X), 1) to represent parity.

The generated code for i32 parity on RV64 has more instructions than
necessary which I hope to improve in a followup patch.

Also add missing test for i64 ctpop.

After D104475 / D104658, building the Linux kernel with ThinLTO is
broken:

ld.lld: error: Unknown attribute kind (73) (Producer: 'LLVM13.0.0git'
Reader: 'LLVM 13.0.0git')

getAttrFromCode() has never handled this attribute so it is written
during the ThinLTO phase but it cannot be handled during the linking
phase.

Add noprofile to getAttrFromCode() so that disassembly works properly.

Reviewed By: MaskRay

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

Preserve address space when inserting i8* cast.

Preserve address space when generating the cast to i8*.

Revert "[RISCV] Use zexti32/sexti32 in srliw/sraiw isel patterns to improve usage of those instructions."

I thought this might help with another optimization I was
thinking about, but I don't think it will. So it just wastes
compile time calling computeKnownBits for no benefit.

This reverts commit 81b2f959.

For the start shortening optimization, always use a i8 type for
the GEP, as it is a raw offset calculation.

Handling of non-i8* memset/memcpy arguments requires insertion
of casts. These cases were previously miscompiled, as the offset
calculation was performed on the wrong type.

Updates Bazel BUILD files for changes in
https://github.com/llvm/llvm-project/commit/0813700de1

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

This is a bug fix of https://bugs.llvm.org/show_bug.cgi?id=50116

Reviewed By: MyDeveloperDay

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

Apparently, it is legal to use memcpy/memset with pointer types
other than i8*. Prior to 81fcdae6
this case was silently miscompiled, as the i8 offset calculation
was performed on some other type. Now it would crash due to a
type mismatch. Fix this by inserting an explicit bitcast to i8*.

This is an extension of the handling for unary intrinsics and
follows the logic that we use for binary ops.

We don't canonicalize to min/max intrinsics yet, but this might
help unlock other folds seen in D98152.

There are remaining redundant bitcasts.

This patch updates VPWidenPHI recipes for first-order recurrences to
also track the incoming value from the back-edge. Similar to D99294,
which did the same for reductions.

Reviewed By: Ayal

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

This would crash later if we thought the parameters were
valid for the standard library call as shown in:
https://llvm.org/PR50846

libunwind uses unwind info to find the function address belonging
to the current instruction pointer. libunwind/src/CompactUnwinder.hpp's
step functions read functionStart for UNWIND_X86_64_MODE_STACK_IND
(and for nothing else), so these encodings need a dedicated entry
per function, so that the runtime can get the stacksize off the
`subq` instrunction in the function's prologue.

This matches ld64.

(CompactUnwinder.hpp from https://opensource.apple.com/source/libunwind/
also reads functionStart in a few more cases if `SUPPORT_OLD_BINARIES` is set,
but it defaults to 0, and ld64 seems to not worry about these additional
cases.)

Related upstream bug: https://crbug.com/1220175

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

D104271 broke buildbots for lld/test/ELF/non-abs-reloc.s .

llvm-dwarfdump was silent even when the format of DWARF was invalid
and/or llvm-dwarfdump did not understand/support some of the constructs.
This can be pretty confusing as llvm-dwarfdump is a tool for DWARF
producers+consumers development.

Review comments also by @dblaikie.

Reviewed By: jhenderson

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

Reduce code duplication: Move various helper functions, that are duplicated in TensorDialect, MemRefDialect, LinalgDialect, StandardDialect, into a new StaticValueUtils.cpp.

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

Don't allow vectors to split into GPRs for 'r' and other scalar
constraints. Prevents assertion in getCopyToPartsVector.

Makes PR50907 give a better error instead of crashing.

Fix the command line guide for -g/-s/-S.
In particular, previously it was incorrectly stating that -S is an alias for --strip-all.

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

We need to mask the immediate to the width of a single vector
rather than 2 vectors. If we use the width of 2 vectors then
any shift larger than the length of 1 vector is going to overflow
the shuffle indices.

Fixes PR50895.

In FreeBSD 14 the project will deprecate the _p special profiling
libraries.

Support for -pg (i.e., mcount) still exists but libraries compiled
with -pg will not be built by default, so stop linking against them.

Reviewed by:	Dimitry Andric
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.llvm.org/D104753

The MVETRUNC node truncates two wide vectors to a single vector with
narrower elements. This is usually lowered to a series of extract/insert
elements, going via GPR registers. This patch changes that to instead
use a pair of truncating stores and a stack reload. This cuts down the
number of instructions at the expense of some stack space.

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