The motivating use case is to have type metadata on vtables if IR instrumentation is on (without the requirement of`-fwhole-program-vtables` or `-flto`).

A related rfc is in
https://discourse.llvm.org/t/rfc-dynamic-type-profiling-and-optimizations-in-llvm/74600

Not used in all cases. Shown by python test ops.

    This commit contains the initial scaffolding to convert the
    functionality currently implemented in LocateSymbolFile to a plugin
    architecture. The plugin approach allows us to easily add new ways to
    find symbols and fixes some issues with the current implementation.

    For instance, currently we (ab)use the host OS to include support for
    querying the DebugSymbols framework on macOS. The plugin approach
    retains all the benefits (including the ability to compile this out on
    other platforms) while maintaining a higher level of separation with the
    platform independent code.

    To limit the scope of this patch, I've only converted a single function:
    LocateExecutableObjectFile. Future commits will convert the remaining
    LocateSymbolFile functions and eventually remove LocateSymbolFile. To
    make reviewing easier, that will done as follow-ups.

Previously only unwrapped values were considered for default values in
builders, expand to Attributes given the change to populate defaults. To avoid
overlap between wrapped and unwrapped, the starting index is incremented
depending on if the smallest starting index for default valued args can be
materialized in unwrapped form or not.

Given the above limitation this is pretty small change.

`optional` is unfortunately meant to also represent conditionally set which
means we cannot allow nullptr for all Attributes marked optional at the moment.

Reviewed By: Mogball

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

Opaque ptr cleanup effort (NFC)

This patch adjusts the inline function decl check for LLVM libc to
ignore implicit functions. For the moment the plan is to ignore these
and mark the class with a macro so that it can be given the appropriate
properties without explicitly defining all its ctors/dtors.

- The latest TOSA spec for CustomOp is having attributes
  - operator_name, domain_name, and implementation_attrs
- Updated the dialect to align with the spec change

Signed-off-by: Jerry Ge <jerry.ge@arm.com>

This commit removes the no longer required `llvm.ptr<i8>` bitcasts from
AMX's legalize-for-llvm-export pass. Typed pointers have been
deprecated for a while now and it's planned to soon remove them from
the LLVM dialect.

Related PSA: https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

Fix a bug introduced in 98c90a13 (ISel: introduce vector ISD::LRINT,
ISD::LLRINT; custom RISCV lowering), where ISD::LRINT and ISD::LLRINT
used WidenVecRes_Unary to widen the vector result. This leads to
incorrect CodeGen for RISC-V fixed-vectors of length 3, and a crash in
SelectionDAG when we try to lower llvm.lrint.vxi32.vxf64 on i686. Fix
the bug by implementing a correct WidenVecRes_XRINT.

Fixes #71187.

[ELF] Improve undefined symbol message w/ DW_TAG_variable of the enclosing symbol but w/o line number information (#70854)

The undefined symbol message suggests the source line when line number
information is available (see https://reviews.llvm.org/D31481).
When the undefined symbol is from a global variable, we won't get the
line information.
```
extern int undef;
namespace ns {
int *var[] = {
  &undef
};
// DW_TAG_variable(DW_AT_decl_file/DW_AT_decl_line) is available while
// line number information is unavailable.
}

ld.lld: error: undefined symbol: undef
>>> referenced by undef-debug2.cc
>>>               undef-debug2.o:(ns::var)
```

This patch utilizes `getEnclosingSymbol` to locate `var` and find
DW_TAG_variable for `var`:
```
ld.lld: error: undefined symbol: undef
>>> referenced by undef-debug2.cc:3 (/tmp/c/undef-debug2.cc:3)
>>>               undef-debug2.o:(ns::var)
```

It seems that currently this section is only created by the mold linker
if 2 conditions are met: 1. The PLT function was called directly. 2. The
indirect access to PLT function was found (e.g. through ADRP
relocation). Although mold created symbol for every plt entry I've
removed them in yaml file to check that .plt.got was truly disassembled
by bolt.

Some specific implementation of the offload may want more customization, and
even avoid using LLVM in-tree to dispatch the ISA translation to a custom
solution. This refactoring makes it possible for such implementation to work
without even configuring the target backend in LLVM.

Reviewers: fabianmcg

Reviewed By: fabianmcg

Pull Request: https://github.com/llvm/llvm-project/pull/71165

This commit removes all LLVM dialect typed pointers from the target
tests. Typed pointers have been deprecated for a while now and it's
planned to soon remove them from the LLVM dialect.

Related PSA:
https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

This commit removes all LLVM dialect typed pointers from the integration
tests. Typed pointers have been deprecated for a while now and it's
planned to soon remove them from the LLVM dialect.

Related PSA:
https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

Revert "Port Swift's merge function pass to llvm: merging functions that differ in constants (#68235)"

This reverts commit 19b5495b.

PR landed without approval, with severe quality issues.

Dsymutil already avoids copying textual Swift interface files from the
SDK, since any consumer would have to have a matching SDK installed
anyway. It should also do the same thing with interfaces found in the
toolchain itself, which includes the compiler built-in libraries such as
Swift (=the standard library), and _Concurrency.

rdar://117881604

Android's librt and libpthread functionality is part of libc.{a,so}
instead. The atomic APIs are part of the compiler-rt builtins archive.
Android does have libdl.

Android's libc.so has `__cxa_thread_atexit_impl` starting in API 23, and
the oldest supported API is 21, so continue using feature detection for
that API.

These settings need to be declared explicitly for the sake of the fuzzer
library's custom libc++ build `add_custom_libcxx`. That macro builds
libc++ using `-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY`, which
breaks the feature detection.

BPF upstream reported an inconsistent behavior w.r.t. BPF_TYPE_ID_LOCAL
vs. BPF_TYPE_ID_TARGET (or BPF_TYPE_ID_REMOTE in LLVM terminology).

For BPF_TYPE_ID_TARGET, all modifiers (like 'const' and 'volatile') are
ignored in the final type encoding. For example, for type
 'const struct foo', the eventually encoding in BTF relocation
is 'struct foo'. This faciliates libbpf to match corresponding kernel
types with considering any modifiers.

Currently behavior for BPF_TYPE_ID_LOCAL is different. It will encode
'const struct foo' in BTF relocation and such discrepancy confused users
([1]).

This patch fixed this discrepancy by making BPF_TYPE_ID_LOCAL BTF type
representation the sams as BPF_TYPE_ID_TARGET. This should have minimum
user impact since ultimately user wants to get a real time not a 'const'
type modifier.

The selftest builtin-btf-type-id-2.ll is used to test BPF_TYPE_ID_TARGET
with 'const' modifier. Adapt the same test for BPF_TYPE_ID_LOCAL. And
the below diff shows now both BPF_TYPE_ID_LOCAL and BPF_TYPE_ID_TARGET
produces the same type:

$ diff test/CodeGen/BPF/BTF/builtin-btf-type-id-2.ll
test/CodeGen/BPF/BTF/builtin-btf-type-id-local.ll
--- test/CodeGen/BPF/BTF/builtin-btf-type-id-2.ll 2023-07-30
16:58:20.657528310 -0700
+++ test/CodeGen/BPF/BTF/builtin-btf-type-id-local.ll 2023-11-02
10:23:25.356959008 -0700
  @@ -6,7 +6,7 @@
   ;     int a;
   ;   };
   ;   int test(void) {
  -;     return __builtin_btf_type_id(*(const struct s *)0, 1);
  +;     return __builtin_btf_type_id(*(const struct s *)0, 0);
   ;   }
   ; Compilation flag:
; clang -target bpf -O2 -g -S -emit-llvm -Xclang -disable-llvm-passes
test.c
  $

[1]
https://lore.kernel.org/bpf/CAN+4W8h3yDjkOLJPiuKVKTpj_08pBz8ke6vN=Lf8gcA=iYBM-g@mail.gmail.com/



Co-authored-by: Yonghong Song <yonghong.song@linux.dev>

[CalcSpillWeights] don't mark live intervals with spillable inlineasm ops as having infinite spill weight (#70747)

This is necessary for RegAllocGreedy support for memory folding inline
asm that uses "rm" constraints.

Thanks to @qcolombet for the suggestion.

Link: https://github.com/llvm/llvm-project/issues/20571

Fixes #65222.
When unfolding select into diamond-like control flow, we need to remove
the StartBlock from all phis in EndBlock.

OpenBSD prefers the use of the endian.h header.

This PR removes the various caching mechanisms currently in the python
bindings - both positive caching and negative caching.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

Also add missing assert message

This reverts commit a6c8e27b.  It appears likely to have caused https://lab.llvm.org/buildbot/#/builders/57/builds/30988.

This adds the nneg flag to SDNodeFlags and the node printing code.
SelectionDAGBuilder will add this flag to the node if the target doesn't
prefer sign extend.

A future RISC-V patch can remove the sign extend preference from
SelectionDAGBuilder.

I've also added the flag to the DAG combine that converts
ISD::SIGN_EXTEND to ISD::ZERO_EXTEND.

See RFC for details:
https://discourse.llvm.org/t/rfc-for-moving-swift-s-merge-function-pass-to-llvm/73778



We will need to refactor extension to FunctionComparator/FunctionHash to
StructuralHash. This patch adds a new pass which is ported from Swift,
and will need to discuss on how to migrate Swift’s pass over after we
land this in llvm.

Create this PR to get some early review on the patch.

---------

Co-authored-by: Manman Ren <mren@meta.com>

For a DSO with all DT_NEEDED entries accounted for, if it contains an
undefined non-weak symbol that shares a name with a non-exported
definition (hidden visibility or localized by a version script), and
there is no DSO definition, we should also report an error. Because the
definition is not exported, it cannot resolve the DSO reference at
runtime.

GNU ld introduced this error-checking in [April
2003](https://sourceware.org/pipermail/binutils/2003-April/026568.html).
The feature is available for executable links but not for -shared, and
it is
orthogonal to --no-allow-shlib-undefined. We make the feature part of
--no-allow-shlib-undefined and work with -shared when
--no-allow-shlib-undefined is specified.

A subset of this error-checking is covered by commit
1981b1b6 for --gc-sections discarded
sections. This patch covers non-discarded sections as well.

Internally, I have identified 2 bugs (which would fail with
LD_BIND_NOW=1) covered by commit
1981b1b6

This patch fixes:

  clang-tools-extra/clang-doc/BitcodeReader.cpp:78:3: error: default
  label in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

These macro can help guarding some tests and other section of code
which rely on detecting if a particular target is available. This
is common the MLIR codegeneration for GPU targets for example.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

As suggested during review of https://github.com/llvm/llvm-project/pull/70990.

This patch converts TagTypeKind into scoped enum. Among other benefits,
this allows us to forward-declare it where necessary.

Currently tryToGatherExtractElements function analyzes the whole vector,
regrdless number of actual registers, used in this vector. It may
prevent some optimizations, because per-register analysis may allow to
simplify the final code by reusing more already emitted vectors and
better shuffles.

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

The body of `OptBisect::checkPass()` was moved to
`OptBisect::shouldRunPass()` in
[D137149](https://reviews.llvm.org/D137149).