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.

We need to handle this when registering global variables.

Test integral pointers as well.

…db-enumerations.h" (#88324)"

This reverts commit 9f6d08f2. This broke
the build because of a usage of one of the original SBDebugger broadcast
bits that wasn't updated in the original commit.

This document discusses some options where the debug metadata can be
generated. It also goes through various language constructs and explains
how the debug metadata will look like for that construct and how we can
extract that information.

The real point of discussion is how and where to extract the information
about various language features to generate the debug metadata. The
structure of the metadata itself is mostly settled as that is dictated by
the DWARF and structure of LLVM IR metadata. The classic flang
and gfortran generate quite similar DWARF for the various language
constructs.

This document is based on what Kiran posted in
https://reviews.llvm.org/D138534

.

---------

Co-authored-by: Tom Eccles <t@freedommail.info>
Co-authored-by: Kiran Chandramohan <kiranchandramohan@gmail.com>

As reported in #86843, we must have #pragma GCC system_header before we
use #include_next, otherwise the compiler may not understand that we're
in a system header and may issue a diagnostic for our usage of

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 whi...

Instead of instantiating `__copy_cv` for every combination of `_From`
and `_To` this only instantiates `__copy_cv` for every `_From` type,
reducing the number of instantiations.

Fixes #87835

This patch added the documentation for the POSIX functions according to
[n3096](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf)
Section 7.14, and gives the *docgen.py* script a more elegant *is_implemented*
function.

Support Tremont CPUs which don't have AVX but do have GFNI.

Noticed while trying to workout how to clean up the costmodel for GFNI bitreverse

 [Flang] [OpenMP] [MLIR] [Lowering] Add lowering support for IS_DEVICE_PTR and HAS_DEVICE_ADDR clauses on OMP TARGET directive.  (#88206)

Added lowering support for IS_DEVICE_PTR and HAS_DEVICE_ADDR clauses for
OMP TARGET directive and added related tests for these changes.

IS_DEVICE_PTR and HAS_DEVICE_ADDR clauses apply to OMP TARGET directive
OpenMP spec states

The **is_device_ptr** clause indicates that its list items are device
pointers.

The **has_device_addr** clause indicates that its list items already
have device addresses and therefore they may be directly accessed from a
target device.

Whereas USE_DEVICE_PTR and USE_DEVICE_ADDR clauses apply to OMP TARGET
DATA directive and OpenMP spec for them states

Each list item in the **use_device_ptr** clause results in a new list
item that is a device pointer that refers to a device address

Each list item in a **use_device_addr** clause that is present in the
device data environment is treated as if it is implicitly mapped by a
map clause on the construct with a map-type of alloc

Fixed build error caused by Squash merge which needs rebase

The approved resolution for CWG2858 changes
[expr.prim.id.qual] p2 sentence 2 to read:
> A declarative _nested-name-specifier_ shall not have a
_computed-type-specifier_.

This patch implements the approved resolution. Since we don't consider
_nested-name-specifiers_ in friend declarations to be declarative (yet),
it currently isn't possible to write a test that would produce this
diagnostic (`diagnoseQualifiedDeclaration` is never called if the
`DeclContext` can't be computed). Nevertheless, tests were added which
will produce the diagnostic once we start calling
`diagnoseQualifiedDeclaration` for friend declarations.

This implementation has a number of issues and ultimately does not work
on gfx9.
* It does not reduce bank conflicts with wide memory accesses.
* It does not correctly account for when LDS bank conflicts occur on
amdgpu.
* The implementation is too fragile to be used on real-world code. For
example, the code bails out on any `memref.subview` in the root op, even
when the subview is not a user of any of the `memref.alloc` ops.

I do not see how these can be easily fixed, therefore I think it's
better to delete this code.

When creating cast(shuffle(x,y)) we were only adding the cast() to the worklist, not the new shuffle, preventing recursive combines.

foldShuffleOfBinops is also failing to do this, but I still need to add test coverage for this.

We are still missing a fold for shuffle(bitcast(sext(x)),bitcast(sext(y))) -> bitcast(sext(shuffle(x,y))) due to foldShuffleOfCastops failing to add new instructions back onto the worklist

For example, 1e30^1.2 currently overflows.

Also forward fastmath flags.

This ports XLA's logic and was verified with its test suite. Note that
rsqrt and sqrt are still broken.