* Generally recommend target triples. But replace `m*version-min` with
`mtargetos`.
* Also include test coverage for -mtargetos=visionos

Removing the intrinsic because there is no opCodes for rcp in DXIL or
SPIR-V.
Moving means we don't have to re-implement this feature for each
backend.

fixes #87784

Co-authored-by: Farzon Lotfi <farzon@farzon.com>

The code returned lldb.SBValue() when you passed in an unrecognized
register name. But referring to "lldb" is apparently not legal within
the module.

I changed this to just return SBValue(), but then this construct:

(lldb) script
>>> for reg_set in lldb.target.process.thread[0].frames[0].register
...    print(reg)

Runs forever printing "No Value". The __getitem__(key) gets called with
a monotonically increasing by 1 series of integers. I don't know why
Python decided the class we defined should have a generator that returns
positive integers in order, but we can add a more useful one here by
returning an iterator over the flattened list of registers.

Note, the not very aptly named "SBFrame.registers" is an iterator over
register sets, not registers, so the two are not redundant.

The `FileEntry` corresponds to a `FileID` containing the
`SourceLocation` of a `NamedDecl` which (I think) might've been
deserialized from a PCM file. Considering external `HeaderFileInfo` here
is most likely the right thing to do here in order to get the correct
spelling in case the current compiler instance has not register this
file as a header yet.

Clang uses the `HeaderFileInfo` struct to track bits of information on
header files, which gets used throughout the compiler. We also use this
to compute the set of affecting module maps in `ASTWriter` and in the
end serialize the information into the `HEADER_SEARCH_TABLE` record of a
PCM file, allowing clients to learn about headers from the module. In
doing so, Clang asks for existing `HeaderFileInfo` for all known
`FileEntries`. Note that this asks the loaded PCM files for the
information they have on each header file in question. This seems
unnecessary: we only want to serialize information on header files that
either belong to the current module or that got included textually.
Loaded PCM files can't provide us with any useful information.

For explicit modules with lazy loading (using `-fmodule-map-file=<path>`
with `-fmodule-file=<name>=<path>`) the compiler knows about header
files listed in the module map files on the command-line. This can be a
large number.

Asking for existing `HeaderFileInfo` can trigger deserialization of
`HEADER_SEARCH_TABLE` from loaded PCM files. Keys of the on-disk hash
table consist of the header file size and modification time. However,
with explicit modules Clang zeroes out the modification time. Moreover,
if you import lots of modules, some of their header files end up having
identical sizes. This means lots of hash collisions that can only be
resolved by running the serialized filename through `FileManager` and
comparing equality of the `FileEntry`. This ends up being super
expensive, essentially re-stating lots of the transitively loaded SDK
header files.

This patch cleans up the API for getting `HeaderFileInfo` and makes sure
`ASTWriter` uses the version that doesn't ask loaded PCM files for more
information. This removes the excessive stat traffic coming from
`ASTWriter` hopefully without changing observable behavior.

Introduce a cmake variable that guards the inclusion of ClangIR into the
build of clang. Guard that we aren't trying to build without MLIR. Add
two subdirectories that, as of now, don't do anything.

Reviewers: bcardosolopes, erichkeane, petrhosek, Ericson2314

Reviewed By: bcardosolopes

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

Reverts llvm/llvm-project#88431. A config variable for the host OS is
unrecognized on the Linux builds and is causing a build failure.

When builds on Darwin are configured with ASan, running tests will emit
a warning about malloc's nano zone (`malloc: nano zone abandoned due to inability to reserve vm space`) that can interfere with the test
output and cause failures. Setting the environment variable
`MallocNanoZone` to 0 will remove this warning and allow the tests to
run as normal.

[NFC][IndirectCallProm] Refactor function-based conditional devirtualization and indirect call value profile update into one helper function (#80762)

* The motivation is to move indirect callee profile update inside the
function-based speculative indirect-call promotion, so that there are
fewer diffs the vtable-based transformation and profile update is
implemented in a follow-up patch.
* The Parent patch is https://github.com/llvm/llvm-project/pull/79381

Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent class scope function template specialization that instantiates to a static member function (#87541)" (#88311)

Reapplies #87541 and addresses the bug which caused expressions naming
overload sets to be incorrectly rebuilt.

This gold thinlto test should have been updated in commit dda73336
(https://github.com/llvm/llvm-project/commit/dda73336ad22bd0b5ecda17040c50fb10fcbe5fb).

It's ok to keep {Inputs/emit-llvm.foo.ll, Inputs/emit-llvm.bar.ll} the
current way for `llvm-as` since the field is optional (see example in
https://github.com/llvm/llvm-project/blob/5d6d8dcd292e0a107b11d378932eee9c2f9ccfc7/llvm/test/Assembler/thinlto-summary.ll#L12-L16)

D33412/D33413 introduced this to support a clang pragma to set section
names for a symbol depending on if it would be placed in
bss/data/rodata/text, which may not be known until the backend. However,
for text we know that only functions will go there, so just directly set
the section in clang instead of going through a completely separate
attribute.

Autoupgrade the "implicit-section-name" attribute to directly setting
the section on a Fuction.

This file seemed to be added unintentionally in
9434c083.

Call site information setting was conditioned on branch information
presence for a given block. However, it's possible to have sampled
profile lacking one or the other for a given basic block.

Iterate over branch profiles and call profiles independently to cover
all recorded profile data.

Depends on https://github.com/llvm/llvm-project/pull/87569

Test Plan: Updated bolt/test/X86/yaml-secondary-entry-discriminator.s

Reviewers: ayermolo, dcci, maksfb, rafaelauler

Reviewed By: maksfb

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

Move BAT parent function lookup outside `getLocationName`, to the
scope where we retrieve `FuncBranchData` linked with the function.

Previously DataAggregator would store branch profile recorded in the
split fragment in `FuncBranchData` associated with the fragment, and
perform name translation in `getLocationName` for symbol name only.
This works for fdata profile which is printed out as-is, but doesn't
work with BAT YAML profile writer which requires a combined profile.

The issue necessitated `fixupBATProfile` which partially addressed the
issue (reassigned inter-fragment calls back into intra-function
branches). However, `fixupBATProfile` fails to address disjoint
profiles (i.e. doesn't merge `FuncBranchData` for fragments back
into parent). This diff eliminates the need for `fixupBATProfile` by
removing the root cause of the issue.

Test Plan: NFC for existing tests

Reviewers: ayermolo, dcci, rafaelauler, maksfb

Reviewed By: maksfb

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

If (f)sub is only operand of llvm.(f)abs or icmp eq/ne 0 (int only), we can consider it as commutative operation, just need to drop wrapping flags for ineteger
operation.

https://alive2.llvm.org/ce/z/GxvxjB for correctness of abs with dropped
flags.

Reviewers: RKSimon

Reviewed By: RKSimon

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

No need need to special-case zero. Section 0 will map to section 0.

Following #85592, add support for nsw/nuw flags of trunc in SCCP.

[lldb][ClangExpressionParser] Don't by default enable Objecitve-C support when evaluating C++ expressions (#87767)

This patch attempts to decouple C++ expression evaluation from
Objective-C support. We've previously enabled it by default (if a
runtime existed), but that meant we're opting into extra work we only
need to do for Objective-C, which complicates/slows down C++ expression
evaluation. Of course there's a valid use-case for this, which is
calling Objective-C APIs when stopped in C++ frames (which Objective-C++
developers might want to do). In those cases we should really prompt the
user to add the `expr --language objc++` flag. To accomodate a likely
frequent use-case where a user breaks in a system C++ library (without
debug-symbols) but their application is actually an Objective-C app, we
allow Objective-C support in C++ expressions if the current frame
doesn't have debug-info.

This fixes https://github.com/llvm/llvm-project/issues/75443 and allows
us to add more `LangOpts.ObjC` guards around the expression evaluator in
the future (e.g., we could avoid looking into the Objective-C runtime
during C++ expression evaluation, which we currently do
unconditionally).

Depends on https://github.com/llvm/llvm-project/pull/87657

[lldb][ClangUserExpression][NFCI] Pass the most specific ExecutionContextScope possible into ClangExpressionParser (#87657)

The `ClangExpressionParser` takes an `ExecutionContextScope` which it
uses to query the `Process`/`Target`/`StackFrame` to set various
compiler options in preparation for parsing an expression.

However, `TryParse` constructs the parser with a `Process` or `Target`,
never a `StackFrame`. So when the parser tries to retrieve the current
`StackFrame` from the `exe_scope`, it doesn't succeed. In future patches
we want to query the `StackFrame` from within the
`ClangExpressionParser` constructor.

This patch simplifies `TryParse`, by removing the redundant `exe_scope`
parameter, and instead uses the `exe_ctx` to derive the most fitting
`exe_scope` to pass into `ClangExpressionParser`.

Not entirely sure how to test this. This patch is a prerequisite to get
subsequent patches that set `LangOpts` based on the current `StackFrame`
to work.

As expected, we need to be a little more careful when the
Function* is created from an integer.

Similar to #88304

SelHWAsan is optimization. We may want to diagnose compiler decisions.
Remarks is the tool for that https://llvm.org/docs/Remarks.html.

This reverts commit 9029e6eb, which was
committed by mistake with the wrong message and fails  https://lab.llvm.org/buildbot/#/builders/221/builds/21958.

Co-authored-by: Sunil Srivastava <sunil.srivastava@sony.com>

The previous build system was adding custom "OpenCL" and "LLVM IR"
languages in CMake to build the builtin libraries. This was making it
harder to build in-tree because the tool binaries needed to be present
at configure time.

This commit refactors the build system to use custom commands to build
the bytecode files one by one, and link them all together into the final
bytecode library. It also enables in-tree builds by aliasing the
clang/llvm-link/etc. tool targets to internal targets, which are
imported from the LLVM installation directory when building out of tree.

Diffing (with llvm-diff) all of the final bytecode libraries in an
out-of-tree configuration against those built using the current tip
system shows no changes. Note that there are textual changes to metadata
IDs which confuse regular diff, and that llvm-diff 14 and below may show
false-positives.

This commit also removes a file listed in one of the SOURCEs which
didn't exist and which was preventing the use of
ENABLE_RUNTIME_SUBNORMAL when configuring CMake.

There's already support for `-print-before-pass-number`, so it makes
sense that we also have a `-print-after-pass-number`. This is especially
useful if you want to print the IR after the very last pass without
resorting to `-print-after-all` and combing through stderr or the IR
file directory.

#88139 adds a parameter to `TemplateTemplateParmDecl::Create`, which is
called in LLDB. This adds the missing argument for that parameter.

uitofp.

Need to use uitofp for unsigned nodes, which are part of minbitwidth
analysis, to correctly handle signedness info.

Some of the feedback was also relevant to other files, and has been
applied there too.

`(icmp uge/ugt (and X, Y), C)` implies both `(icmp uge/ugt X, C)` and
`(icmp uge/ugt Y, C)`. We can use this to deduce leading ones in `X`.

`(icmp ule/ult (or X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce leading zeros in `X`.

Closes #86059

…r encodings.

This patch adds a `Typename` bit-field to `TemplateTemplateParmDecl`
which stores whether the template template parameter was declared with
the `typename` keyword.

When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MUST match the ABI of the system being overlayed onto;
fullbuild more flexible (the only system ABI relevant is the OS kernel).

When implementing llvm-libc we generally prefer the include-what-you use
style of avoiding transitive dependencies (since that makes refactoring
headers more painful, and slows down build times). So what header do you
include for any given type or function declaration? For any given
userspace program, the answer is straightforward. But for llvm-libc
which is trying to support multiple ABIs (at least one per
configuration), the answer is perhaps less clear.

This proposal seeks to add one layer of indirection relative to what's
being done today.

It then converts users of sigset_t and struct epoll_event and the epoll
implemenations over to this convention as an example.

In order to support various external frameworks (JAX vs PyTorch) we need
a bit more flexibility in [dis]assembling external buffers to and from
sparse tensors in MLIR land. This PR adds a direct-out option that
avoids the rigid pre-allocated for copy-out semantics.

Note that over time, we expect the [dis]assemble operations to converge
into something that supports all sorts of external frameworks. Until
then, this option helps in experimenting with different options.