[mlir] Return new scf.forall handle in fuse_into_containing_op

Since the scf.forall is now consumed by the fuse into
containing op, we need to return a handle to the new scf.forall.
This patch does that and also ensures that the new bbArg
added to the scf.forall is used in its body.

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

[Pipeline] Don't run EarlyFPM in LTO post link

EarlyFPM cleans up the output of the frontend. This isn't necessary in post link pipelines as the pre link pipeline already ran this.

~0.4% savings in ThinLTO builds:
https://llvm-compile-time-tracker.com/compare.php?from=8a5d4eb775c644d8683f24817d44c510d2b853b7&to=3580252a2162eadca0da99f1eeaa112f74a0353d&stat=instructions:u

Reviewed By: tejohnson

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

[unittest][codegen] Avoid memory leak in recently added FindDebugLocTest unittest

Need to finalize the DIBuilder to avoid leak sanitizer errors
like this:

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x55c99ea1761d in operator new(unsigned long)
    #1 0x55c9a518ae49 in operator new
    #2 0x55c9a518ae49 in llvm::MDTuple::getImpl(...)
    #3 0x55c9a4f1b1ec in getTemporary
    #4 0x55c9a4f1b1ec in llvm::DIBuilder::createFunction(...)

[mlir][bytecode] Avoid recording null arglocs & realloc opnames.

For block arg locs a common case is no/uknown location (where the producer
signifies they don't care about blockarg location). Also avoid needing to
dynamically resize opnames during parsing.

Assumed to be post lazy loading change, so chose version 3.

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

[mlir] Change the order of members in MLIRContext to ensure dialects are destroyed first

Currently, the dialects precede the registered operations in the context object, which means that the latter is destroyed first. At the same time, Operation::~Operation dereferences the registered operation when destroying properties, which can cause use-after-free (e.g. if a dialect owns an op). This patch fixes that by changing the order of the members so that dialects come after registered operations.

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

[StandardInstrumentations] Add option to dump IR to a file on crash

We already have -print-on-crash which dumps the IR to stderr on a crash, but it's more useful to dump to a file.

Introduce -print-on-crash-path to dump the IR to a file.

Making -print-on-crash a string option is confusing if you only pass -print-on-crash and it swallows up the next command line arg, which is why this is a new option.

Perhaps we could retire the dump to stderr version if people don't use it, but not sure how much people find that useful.

Reviewed By: jamieschmeiser

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

Discussion: Darwin Sanitizers Stable ABI

# Darwin Sanitizers Stable ABI

We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and novel approaches to ASan for developers, researchers and others.

## Details

Rather than adding a lot of conditional code to the LLVM instrumentation phase, which would incur excessive complexity and maintenance cost of adding conditional code into all places that emit a runtime call, we propose a “shim” layer which will map the unstable ABI to the stable ABI:

* A static library (.a library) shim that maps the existing ASan ABI to a generalized, smaller and stable ABI. The library would implement the __asan functions and call into the new ABI. For example:
    * `void __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); }`
    * `void __asan_load2(uptr p) { __asan_abi_loadn(p, 2, true); }`
    * `void __asan_noabort_load16(uptr p) { __asan_abi_loadn(p, 16, false); }`
    * `void __asan_poison_cxx_array_cookie(uptr p) { __asan_abi_pac(p); }`
* This “shim” library would only be used by people who opt in: A compilation flag in the Clang driver will be used to gate the use of the stable ABI workflow.
* Utilize the existing ability for the ASan instrumentation to prefer runtime calls instead of inlined direct shadow memory accesses.
* Pursue (under the new driver flag) a better separation of abstraction and implementation with:
    * LLVM instrumentation: Calling out for all poisoning, checking and unpoisoning.
    * Runtime: Implementing the stable ABI and being responsible of implementation details of the shadow memory.

## Maintenance

Our aim is that the maintenance burden on the sanitizer developer community be negligible. Stable ABI tests will always pass for non-Darwin platforms. Changes to the existing ABI which would require a change to the shim have been infrequent as the ASan ABI is already relatively stable. Rarely, a change that impacts the contract between LLVM and the shim will occur. Among such foreseeable changes are: 1) changes to a function signature, 2) additions of new functions, or 3) deprecation of an existing function. Following are some examples of reasonable responses to those changes:

* Example: An existing ABI function is changed to return the input parameter on success or NULL on failure. In this scenario, a reasonable change to the shim would be to modify the function signature appropriately and to simply guess at a common-sense implementation.
    * `uptr __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); return p; }`
* Example: An additional function is added for performance reasons. It has a very similar function signature to other similarly named functions and logically is an extension of that same pattern. In this case it would make sense to apply the same logic as the existing entry points:
    * `void __asan_load128(uptr p) { __asan_abi_loadn(p, 128, true); }`
* Example: An entry point is added to the existing ABI for which there is no obvious stable ABI implementation: In this case, doing nothing in a no-op stub would be acceptable, assuming existing features of ASan can still work without an actual implementation of this new function.
    * `void __asan_prefetch(uptr p) { }`
* Example: An entrypoint in the existing ABI is deprecated and/or deleted:
    * (Delete the entrypoint from the shim.)

We’re looking for buy-in for this level of support.

(Note: Upon acceptance of the general concepts herein, we will add a controlling clang flag, cmake integration, contract for the stable ABI, and the appropriate test infrastructure.)

Reviewed By: eugenis, vitalybuka, MaskRay

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

[asan] Fix Windows tests after StripFunctionName() improvements

Stacktraces should no longer show __asan_wrap_, but the "normal"
function name.

Reflect that in tests.

[flang][hlfir] Use actual type when copying an actual argument variable

The copy must made according to the actual type, not the dummy type. In
case the dummy is polymorphic, these types will be different and the
dynamic type of the copy passed in the call should be the one of the
actual.

There is no support for "class(t), value" yet (it is hitting a TODO in
CallInterface that is moot for HLFIR but has not been lifted for lack of
proper testing) so the bug was dormant, but D151271 created a situation
where a copy is needed with polymorphic dummies and exposed the bug.
This led to a compile time assert
"value.isScalar() && fir::isa_trivial(value.getType())" in "hlfir::genAssociateExpr".

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

[InlineCost] Consider branches with !make.implicit metadata as free.

!make.implicit metadata attached to branch means it will very likely
be eliminated (together with associated cmp instruction).

Reviewed By: apilipenko

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

sanitizer-common: temporarily disable release_to_os test for powerpc64

release_to_os has been failing on powerpc64 since yesterday. Temporarily disabling the test to prevent this error from
hiding other potential problems.

[ADT] Allow specifying the size of resulting `SmallVector` in `map_to_vector`

This patch adds an overload for the `map_to_vector` helper template, exposing a parameter to control the size of the resulting `SmallVector`. A few call sites in mlir are updated to illustrate and test the change.

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

[ThinLTO] Disable partial sample profile scaling by default

As pointed out in
https://discourse.llvm.org/t/undeterministic-thin-index-file/69985, the
block count added to distributed ThinLTO index files breaks incremental
builds on ThinLTO - if any linked file has a different number of BBs,
then the accumulated sum placed in the index files will change, causing
all ThinLTO backend compiles to be redone.

This was only used for partial sample profiles, and was therefore
removed for other cases (3adc6e03080c6d38a51f5c5b6744b7c0d9c7541b).

Subsequent testing did not show a performance effect of disabling this
feature even for partial sample profiles. Therefore, switch the default
to false. If this does not cause a noticeable performance degradation
after the default flip, we can remove this support completely.

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

Avoid pointless canonicalize when using Dwarf names

CPU profile indicated memcmp was hot due to the two rfind calls in
getCanonicalFnName. If UseSymbolTable is false, we can avoid the cost entirely.

For CSSPGO profiles I've measured ~5% speedup with this change.

Profile similarity before/after matches 100%.

Reviewed By: wenlei

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

[mlir] Enable folding memref alias for`vector.load`

This work enables  folding memref alias pass for`vector.load`

Reviewed By: qcolombet

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

[KnownBits] Simplify shl. NFCI.

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

[APInt] Add unsigned overloads of shift functions

Add overloads of sshl_ov, ushl_ov, sshl_sat and ushl_sat that take the
shift amount as unsigned instead of APInt. This matches what we do for
the normal shift operators and can help to avoid creating temporary
APInts in some cases.

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

[libc][test] Drastically reduce mem test runtime

Reviewed By: lntue

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

[KnownBits] Check functions that return zero for poison results

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

[libc++][PSTL] Make sure that -fexperimental-library enables the PSTL

@Mordante noticed that this was missing while making `<format>` non-experimental.

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits, Mordante

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

[libc++] Forward to std::{,w}memchr in std::find

Reviewed By: #libc, ldionne

Spies: Mordante, libcxx-commits, ldionne, mikhail.ramalho

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

[RISCV] Add test coverage for shuffle/insert idioms which can become v(f)slide1ups

[clang][dataflow] Fix a crash in `getLogicOperatorSubExprValue()`.

This patch adds a test that crashes without the fix.

Reviewed By: ymandel

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

[GlobalIsel][X86] fix legalization of G_CTLZ and G_CTPOP

Note that the builders are protected by is64Bit().

More fine-grained availibility checks.

Reviewed By: RKSimon

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

[ELF] x86-64: place .lrodata, .lbss, and .ldata away from code sections

The x86-64 medium code model utilizes large data sections, namely .lrodata,
.lbss, and .ldata (along with some variants of .ldata). There is a proposal to
extend the use of large data sections to the large code model as well[1].

This patch aims to place large data sections away from code sections in order to
alleviate relocation overflow pressure caused by code sections referencing
regular data sections.

```
.lrodata
.rodata
.text     # if --ro-segment, MAXPAGESIZE alignment
RELRO     # MAXPAGESIZE alignment
.data     # MAXPAGESIZE alignment
.bss
.ldata    # MAXPAGESIZE alignment
.lbss
```

In comparison to GNU ld, which places .lbss, .lrodata, and .ldata after .bss, we
place .lrodata above .rodata to minimize the number of permission transitions in
the memory image.

While GNU ld places .lbss after .bss, the subsequent sections don't reuse the
file offset bytes of BSS.

Our approach is to place .ldata and .lbss after .bss and create a PT_LOAD
segment for .bss to large data section transition in the absence of SECTIONS
commands. assignFileOffsets ensures we insert an alignment instead of allocating
space for BSS, and therefore we don't waste more than MAXPAGESIZE bytes. We have
a missing optimization to prevent all waste, but implementing it would introduce
complexity and likely be error-prone.

GNU ld's layout introduces 2 more MAXPAGESIZE alignments while ours
introduces just one.

[1]: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU "Large data sections for the large code model"

With help from Arthur Eubanks.

Co-authored-by: James Y Knight <jyknight@google.com>
Reviewed By: aeubanks, tkoeppe

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

[flang][hlfir] address post-commit comments from D151247 and D151251

Addresses comments not addressed in https://reviews.llvm.org/D151251
and https://reviews.llvm.org/D151247

- Fix typo in comments.
- Update an expected test output to include the fir.allocmem argument.
- Make a more generic type comparisons and cast when fetching value
  back from the AnyValueStack temporary storage.

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

[NFC][DAGCombiner]: Only consider nodes with no uses for pruning when forming initial worklist

When the worklist is initially being formed, there is no need to
consider all nodes for pruning. This is because the first time calling
getNextWorklistEntry will only clear those nodes which have no uses,
with their operands being added to the worklist. However, when the worklist is
created for the first time all nodes are added anyways, so this operation
actually ends up adding no nodes.

This patch adds a parameter IsCandidateForPruning to AddToWorklist with a
default value of true to avoid having to update every call site.

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

Fix build file for https://github.com/llvm/llvm-project/commit/12648492998bd22d268eb1d4d476c6c3acc6c43d

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

[RISCV] Fix -Wunused-variable in release builds. NFCI

Fix -Wunused-variable in release builds

Reviewed By: krasimir

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

[X86] Regenerate x86-32-intrcc.ll test checks

This will allow us to improve the diffs for D151400

[CodeGen] Fix for MachineBasicBlock::rfindDebugLoc(instr_rend())

Make sure we do not crash in rfindDebugLoc when starting at
instr_rend(). Solution is to see it as we start one MI before the
first MI, so we can start searching forward at instr_begin()
instead.

This behavior is similar to how findPrevDebugLoc(instr_end()) works.

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

[CodeGen] Add unittest for findDebugLoc, rfindDebugLoc, findPrevDebugLoc and rfindPrevDebugLoc. NFC

- Add some unittests for the findDebugLoc, rfindDebugLoc,
  findPrevDebugLoc and rfindPrevDebugLoc helpers in MachineBasicBlock.

- Clean up code comments and code formatting related to the functions
  mentioned above.

This was extracted as a pre-commit to D150577, adn some of the tests
are commented out since they would crash/assert in a rather
uncontrolled way.

[DWARFLinker] Set size of location expression of DW_FORM_block1 properly.

This patch fixes the problem introduced by D147066. As D147066 may change
the contents of location expression, it started to calculate final attribute
size. This patch uses more correct way to calculate size: DIEValue::sizeOf().

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

[clang][dataflow][NFC] Remove unused variable.

Thanks to chapuni to pointing this out on
https://reviews.llvm.org/D151183.

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

[sanitizer_common] Fix StripFunctionName() on Windows

Also implement StripFunctionName() on Windows to properly strip
interceptor prefixes.

Reported-by: https://lab.llvm.org/buildbot#builders/127/builds/48810

[mlir] Enable folding memref alias for `ldmatrix`

Folding mechanism does not recognize `ldmatrix` op. This work helps pass to recognize the op and fold the memref aliases.

Reviewed By: nicolasvasilache

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

[flang][hlfir] fix regression in inline elementals

InlineElementals created a regression when inlining elemental
expressions where the type of the result of the hlfir.apply does not
match the hlfir.yield.

This patch ensures the pass doesn't match in these cases, fixing the
regression.

It isn't clear to me what the /right/ solution is:
 - Is it actually valid for the hlfir.apply to have a different type
   (even just different array bounds?). Should this be enforced in the
   verifier?
 - Inserting a convert if these types don't match doesn't work because
   fir.convert doesn't know how to convert a hlfir.expr. Should this be
   added?

Test case is from @vzakhari

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

[Lex] Warn when defining or undefining any builtin macro

Currently we warn when MI->isBuiltinMacro, but this is only true for
builtin macros that require processing when expanding. Checking
SourceMgr.isWrittenInBuiltinFile in addition to this will mean that
we catch all builtin macros, though we shouldn't warn on feature test
macros.

As part of doing this I've also moved the handling of undefining from
CheckMacroName to HandleUndefDirective, as it doesn't really make
sense to handle undefining in CheckMacroName but defining in
HandleDefineDirective. It would be nice to instead handle both in
CheckMacroName, but that isn't possible as the handling of defines
requires looking at what the name is being defined to.

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

[IRTranslator][NFC] Refactor if/else chain into early returns

This will make it easier to add more cases in a subsequent commit and also
better conforms to the coding guidelines.

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

[gn build] Port e837f4b7dbc3

[gn] port e837f4b7dbc3 (_LIBCPP_PSTL_CPU_BACKEND_SERIAL)

[AArch64] add missing prfm-slc disassembly test

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

[sanitizer_common] Check 'demangle' flag in StripFunctionName and DemangleFunctionName

To allow getting the original stack trace.

Reviewed By: dvyukov

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

[msan] Strip __interceptor_ from reports

Showing __interceptor_ as part of the function name in reports does not
make sense and is distracting.

Strip the interceptor function name before printing.

Reviewed By: dvyukov, vitalybuka

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

[sanitizer_common] Support stripping interceptor prefixes in RenderFrame()

Rather than having every tool pass the right interceptor prefix, just
move this logic into RenderFrame().

Note that currently there are a few cases where due to aliasing the
intercepted function -> interceptor, the unwinder sees the intercepted
function - however this is never guaranteed. In a later change this
becomes more apparent, and other non-tsan sanitizer tests would fail as
well. By making the default RenderFrame() strip interceptor prefixes, we
don't rely on the linker aliasing preferences.

Reviewed By: dvyukov, vitalybuka, MaskRay

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

[compiler-rt] Unify Linux and *BSD interceptors more

The Linux and *BSD interceptors are almost identical, except for *BSD,
where the overridden intercepted function is not defined weak due to
some incompliant linker behaviour.

Since most of the interception machinery is shared between Linux and
*BSD (see INTERCEPT_FUNCTION macro), it makes sense to unify interceptor
definition and declarations as much as possible to ease future changes.

NFC.

Reviewed By: dvyukov, vitalybuka

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

[compiler-rt] Introduce asm macros for interceptor trampolines

This introduces macros for asm sources to define trampolines, and
aliases to trampolines.

Because we currently do not yet have any real trampolines, this change
is a NFC.

Reviewed By: dvyukov, vitalybuka

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

[compiler-rt] Introduce the notion of an interceptor trampoline

To make the interceptor implementation more flexible, allowing for 2
levels of indirection instead of just 1 in the current scheme (where the
intercepted function aliases the interceptor implementation), introduce
the notion of an interceptor "trampoline".

A trampoline may be a real function (and not just an alias, where
aliases of aliases do not work), which will simply forward to the
interceptor implementation; the intercepted function will then alias the
trampoline:

func -[alias]-> trampoline -[call]-> interceptor

Make the necessary changes to prepare for introducing real trampolines.

This change does not yet introduce any real trampolines, and so
trampoline == interceptor, and we currently still just have:

func -[alias]-> interceptor

NFC.

Reviewed By: dvyukov, vitalybuka, MaskRay

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

[flang][hlfir] Generate temporary storage in Forall/Where [2/2]

Generate temporary storage inside WHERE and FORALL using the temporary
stack runtime. This covers all cases outside of LHS temporary, where the
descriptor stack will have to be used.

Reviewed By: vzakhari

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

[flang][hlfir] Generate temporary storage in Forall/Where [1/2]

Generate temporary storage inline inside WHERE and FORALL when possible.
A following patch will use the runtime to cover the generic cases.

Reviewed By: vzakhari

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

[GuardUtils] Allow intermmediate blocks between widenable branch and deopt block

Reviewed By: anna
Differential Revision: https://reviews.llvm.org/D151082

[mlir] Add pass to enable Armv9 Streaming SVE mode

This patch adds a pass 'enable-arm-streaming' that enables the Armv9
Scalable Matrix Extension (SME) Streaming SVE (SSVE) mode [1] by adding
either of the following attributes to 'func.func' ops:

  * arm_streaming (default)
  * arm_locally_streaming

PATCH [2 / 2] in series for RFC: https://discourse.llvm.org/t/rfc-supporting-armv9-scalable-matrix-extension-sme-streaming-sve-ssve-mode-in-mlir/70678

[1] https://developer.arm.com/documentation/ddi0616/aa

Reviewed By: awarzynski, dcaballe

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

[mlir][llvm] Add arm_streaming LLVM function attributes

This patch adds two optional attributes to 'llvm.func' op for the Armv9
Streaming SVE (SSVE) mode [1] that map 1-1 with LLVM function attributes [2]:

  * arm_streaming -> aarch64_pstate_sm_enabled
  * arm_locally_streaming -> aarch64_pstate_sm_body

Streaming-mode is part of the interface (ABI) for functions with the
first attribute and it's the responsibility of the caller to manage
PSTATE.SM on entry/exit to functions with this attribute [3]. The LLVM
backend will emit 'smstart sm' / 'smstop sm' [4] around calls to
streaming functions.

In locally streaming functions PSTATE.SM is kept internal and managed by
the callee on entry/exit. The LLVM backend will emit 'smstart sm' /
'smstop sm' in the prologue / epilogue for functions with this
attribute.

The integration test for SSVE has been updated to no longer use the
passthrough mechanism that's intended for prototyping.

PATCH [1 / 2] in series for RFC: https://discourse.llvm.org/t/rfc-supporting-armv9-scalable-matrix-extension-sme-streaming-sve-ssve-mode-in-mlir/70678

[1] https://developer.arm.com/documentation/ddi0616/aa
[2] https://llvm.org/docs/AArch64SME.html#introduction
[3] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#671pstatesm-interfaces
[4] https://developer.arm.com/documentation/ddi0602/2023-03/Base-Instructions/SMSTART--Enables-access-to-Streaming-SVE-mode-and-SME-architectural-state--an-alias-of-MSR--immediate--

Reviewed By: awarzynski, dcaballe, WanderAway

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

[NFC] Add more python reformat SHA to .git-blame-ignore-revs

[NFC][Py Reformat] Reformat python files in the rest of the dirs

This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: jhenderson, #libc, Mordante, sivachandra

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

[NFC] Add libcxx python reformat SHA to .git-blame-ignore-revs

[NFC][Py Reformat] Reformat python files in libcxx/libcxxabi

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: #libc, kwk, Mordante

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

Revert "[SelectionDAG] Handle NSW for ADD/SUB in computeKnownBits()"

This reverts commit b66551370fdfc6f357ae0d77237119d2b1077b62.

This has exposed a pre-existing miscompile, reported in
https://reviews.llvm.org/D150769#4370467.

Revert "[-Wunsafe-buffer-usage] Group variables associated by pointer assignments"

This reverts commit ee6b08e99375fc48d1e5848704a66c2e8e57eb3b.

One of the added tests warn-unsafe-buffer-usage-multi-decl-warnings.cpp does
not seem to be deterministic, and seems to be especially problematic on Windows.

Failures of this one test on llvm-clang-x86_64-sie-win:
- https://lab.llvm.org/buildbot/#/builders/216/builds/21758
- https://lab.llvm.org/buildbot/#/builders/216/builds/21761
- https://lab.llvm.org/buildbot/#/builders/216/builds/21762
- https://lab.llvm.org/buildbot/#/builders/216/builds/21765
- https://lab.llvm.org/buildbot/#/builders/216/builds/21770
- https://lab.llvm.org/buildbot/#/builders/216/builds/21771
- https://lab.llvm.org/buildbot/#/builders/216/builds/21773
- https://lab.llvm.org/buildbot/#/builders/216/builds/21776
- https://lab.llvm.org/buildbot/#/builders/216/builds/21777
- https://lab.llvm.org/buildbot/#/builders/216/builds/21778
- https://lab.llvm.org/buildbot/#/builders/216/builds/21779

Other random bot failures:
- https://lab.llvm.org/buildbot/#/builders/65/builds/9821
- https://lab.llvm.org/buildbot/#/builders/65/builds/9822
- https://lab.llvm.org/buildbot/#/builders/65/builds/9824
- https://lab.llvm.org/buildbot/#/builders/119/builds/13440
- https://lab.llvm.org/buildbot/#/builders/119/builds/13442
- https://lab.llvm.org/buildbot/#/builders/119/builds/13444
- https://lab.llvm.org/buildbot/#/builders/119/builds/13445
- https://lab.llvm.org/buildbot/#/builders/60/builds/12156
- https://lab.llvm.org/buildbot/#/builders/60/builds/12157
- https://lab.llvm.org/buildbot/#/builders/60/builds/12160

[FuncSpec] Enable specialization of literal constants.

To do so we have to tweak the cost model such that specialization
does not trigger excessively.

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

[clang][dataflow] Add support for return values of reference type.

This patch changes the way `Environment::ReturnLoc` is set: Whereas previously it was set by the caller, it is now set by the callee (obviously, as we otherwise would not be able to return references).

The patch also introduces `Environment::ReturnVal`, which is used for non-reference-type return values. This allows these to be handled with the correct value category semantics; see also https://discourse.llvm.org/t/70086, which describes the ongoing migration to strict value category semantics.

Depends On D150776

Reviewed By: ymandel, xazax.hun

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

[RISCV] Don't reduce vslidedown's VL in rotations

Even though we only need to write to the bottom NumElts - Rotation
elements for the vslidedown.vi, we can save an extra vsetivli toggle if
we just keep the wide VL.

(I may be missing something here: is there a reason why we want to explicitly keep the vslidedown narrow?)

Reviewed By: craig.topper

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

[CodeGen][ShrinkWrap] Enable PostShrinkWrap by default

This is an attempt to reland D42600 and enabling this optimisation by default.

This also resolves the issue pointed out in the context of PGO build.

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

-fsanitize=function: fix alignment fault on Arm targets.

Function pointers are checked by loading a prefix structure from just
before the function's entry point. However, on Arm, the function
pointer is not always exactly equal to the address of the entry point,
because Thumb function pointers have the low bit set to tell the BX
instruction to enter them in Thumb state. So the generated code loads
from an odd address and suffers an alignment fault.

Fixed by clearing the low bit of the function pointer before
subtracting 8.

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

[KnownBits] Add support for nuw/nsw on shifts

Implement precise nuw/nsw support in the KnownBits implementation,
replacing the rather crude handling in ValueTracking.

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

[mlir] Removing unnecessary includes from Memref dialect

`MemRefMemorySlot.cpp` had two unused includes without a cmake
dependency on the dialects they were in. Led to build failures.

Reapply [SCEV] Replace IsAvailableOnEntry with block disposition

This exposed an issue in SCEVExpander/LCSSA, which has been fixed
in D150681.

-----

As far as I understand, the IsAvailableOnEntry() function basically
implements the same functionality as the properlyDominates() block
disposition. The primary difference (apart from a weaker
implementation) seems to be in this comment at the top:

    // Checks if the SCEV S is available at BB.  S is considered available at BB
    // if S can be materialized at BB without introducing a fault.

However, I don't really understand why there would be such a
requirement. It's my understanding that SCEV explicitly does not
care about trapping udiv instructions itself, and it's the job of
SCEVExpander's isSafeToExpand() to make sure these don't get
expanded if they may trap.

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

[clangd] Dont run raw-lexer for OOB source locations

We can get stale source locations from preamble, make sure we don't
access those locations without checking first.

Fixes https://github.com/clangd/clangd/issues/1636.

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

[SCEVExpander] Remember phi nodes inserted by LCSSA construction

SCEVExpander keeps track of all instructions it inserted. However,
it currently misses some phi nodes created during LCSSA construction.
Fix this by collecting these into another argument.

This also removes the IRBuilder argument, which was added for
essentially the same purpose, but only handles the root LCSSA nodes,
not those inserted by SSAUpdater.

This was reported as a regression on D149344, but the reduced test
case also reproduces without it.

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

Fix MLIR bytecode loading of resources

The bytecode reader didn't handle properly the case where resource names
conflicted and were renamed, leading to orphan handles in the IR as well
as overwriting the exiting resources.

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

Specialize OwningOpRef::operator-> to work with pointers like Operation*

This just simplifies user code.

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

Fix MLIR bytecode reader for unregistered dialects

At the moment we accept (in tests) unregistered dialects and in particular:

  "new_processor_id_and_range"()

where there is no `.` separator. We probably will remove support for this
from the parser, but for now we're adding compatibility support in the
reader.

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

[mlir][IR] Improve `clone` function return type of shaped types

There are `clone` overloads that take a shape as a parameter. These overloads are guaranteed to return a ranked shaped type.

`TensorType::clone`/`BaseMemRefType::clone` used to always return a `TensorType`/`BaseMemRefType`. The variants that take a shape parameter now return a `RankedTensorType`/`MemRefType`. Better static type information can make extra casts at the call site obsolete.

E.g.:
```
{TensorType/RankedTensorType} t;
t.clone({1, 2})  // now returns RankedTensorType instead of TensorType
```

Also improve documentation for `clone`.

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

[RISCV][NFC] Simplify decoding code of disassembler

The decoding parts are reduplicative, we add a macro to simplify
the code.

Reviewed By: craig.topper, kito-cheng

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

[libc++][spaceship][NFC] Improved consistency - removed `inline` specifier for `operator<=>`

Removed `inline` specifier for consistency as discussed in D148416 previously.

Reviewed By: #libc, Mordante

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

[clang][dataflow] Add a `ControlFlowContext::build()` overload taking a `FunctionDecl`.

This is the most common use case, so it makes sense to have a specific overload for it.

Reviewed By: xazax.hun

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

[mlir][Transforms][NFC] GreedyPatternRewriteDriver: Add worklist class

Encapsulate all worklist-related functionality in a separate `Worklist` class. This makes the remaining code more readable and allows for custom worklist implementations (e.g., a randomized worklist for fuzzing pattern application: D142447).

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

[lld][ELF] Implement –print-memory-usage

This option was introduced in GNU ld in
https://sourceware.org/legacy-ml/binutils/2015-06/msg00086.html and is
often used in embedded development. This change implements this option
in LLD matching the GNU ld output verbatim.

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

[mlir][sparse] Fix incorrect API usage in RewritePatterns

Incorrect API usage was detected by
`MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS`.

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

[Clang][RISCV] Update all RVV intrinsic auto-generated test case with new script. NFC

This commit updates all intrinsics under
`clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated` because the
new script of `update_llc_test_checks.py` is generating many new lines
differently.

This NFC commit updates the test cases in a whole batch.

Signed-off by: eop Chen <eop.chen@sifive.com>

[libc][bazel] Add targets for fmod* and scalbn*.

Reviewed By: lntue

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

[libc] Make hermetic test depend on the unit test if it exists.

We want to do this so that build system like ninja don't end up running
the hermetic and unit tests in parallel. Running in parallel can cause
problems for tests which read/write disk files as the hermetic and unit
tests can end up stepping on each other.

Reviewed By: jhuber6

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

[RISCV][CodeGen] Support Zdinx on RV32 codegen

This patch was split from D122918 .

Co-Author: @StephenFan @liaolucy @realqhc

Reviewed By: craig.topper

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

[MC] Check if register is non-null before calling isSubRegisterEq (NFCI)

D151036 adds an assertions that prohibits iterating over sub- and
super-registers of a null register. This is already the case when
iterating over register units of a null register, and worked by
accident for sub- and super-registers.

Reviewed By: Amir

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

[libc] Rearrange error and signal tables.

This is largely a cosmetic change done with a few goals:
1. Reduce the conditionals in picking the correct set of tables for the
   platform.
2. Avoid exposing, for example Linux errors, when building for non-Linux
   platforms. This also prevents build failures when Linux errors are not
   defined on the target non-Linux platform.
3. Some "_table" suffixes have been removed to avoid repeated
   occurance of "table" like "tables/linux_error_table.h".

Reviewed By: michaelrj

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

[mlir][sparse][gpu] various cuSparse refinements

(1) keep all cuSparse ops on single stream without wait() in right order
(2) use more type precise memref types for COO
(3) use ToTensor on resulting memref (even though it folds away again)

Reviewed By: K-Wu

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

[mlir][spirv] Add OpConvertPtrToU and OpConvertUToPtr ops

Add the definitions and necessary verifications of these Ops.

Reviewed By: antiagainst

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

sanitizer-common: fix buildbot by temporarily disabling release_to_os test for tsan

This has been causing substantial redness in the buildbots e.g.,
https://lab.llvm.org/buildbot/#/builders/239/builds/2405
which already contained a commit to deflake the test
(https://github.com/llvm/llvm-project/commit/3afd1b2c357fb5353084a736d885af60115d6acb).
Temporarily disabling the test to prevent this error from
hiding other potential problems.

[MIPS] Check if register is non-null before calling isSuperOrSubRegisterEq (NFCI)

D151036 adds an assertions that prohibits iterating over sub- and
super-registers of a null register. This is already the case when
iterating over register units of a null register, and worked by
accident for sub- and super-registers.

Reviewed By: MaskRay

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

[CodeGen] Skip null physical register in AntiDepBreaker (NFCI)

D151036 adds an assertions that prohibits iterating over sub- and
super-registers of a null register. This is already the case when
iterating over register units of a null register, and worked by
accident for sub- and super-registers.
The only place where the assertion is currently triggering is in
CriticalAntiDepBreaker::ScanInstruction. Other places are changed
in case new assertions are added and should be harmless otherwise.

Revert "[CodeGen] Skip null physical register in AntiDepBreaker (NFCI)"

This reverts commit d41f6cff030369d99ad62bbdba732552c08d48a6.

The commit contained wrong phabricator link.

[NFC][CLANG] Fix issue with dereference null return value found by Coverity

Reported by Static Analyzer Tool, Coverity:

Inside "SemaDeclCXX.cpp" file, in clang::Sema::CheckExplicitlyDefaultedSpecialMember(clang::CXXMethodDecl *, clang::Sema::CXXSpecialMember, clang::SourceLocation): Return value of function which returns null is dereferenced without checking.

  //returned_null: getAs returns nullptr (checked 117 out of 143 times).
  // var_assigned: Assigning: Type = nullptr return value from getAs.
  const FunctionProtoType *Type = MD->getType()->getAs<FunctionProtoType>();

  //Dereference null return value (NULL_RETURNS)
  //dereference: Dereferencing a pointer that might be nullptr Type when calling getReturnType.
  ReturnType = Type->getReturnType();

  //Dereference null return value (NULL_RETURNS)
  //dereference: Dereferencing a pointer that might be nullptr Type when calling getParamType.
  QualType ArgType = ExpectedParams ? Type->getParamType(0) : QualType();

This patch uses castAs instead of getAs which will assert if the type doesn't match.

Reviewed By: erichkeane

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

[mlir][python] Hook up PyRegionList.__iter__ to PyRegionIterator

This fixes a -Wunused-member-function warning, at the moment
`PyRegionIterator` is never constructed by anything (the only use was
removed in D111697), and iterating over region lists is just falling
back to a generic python iterator object.

Reviewed By: stellaraccident

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

[gcov] Add nosanitize metadata to memory access instructions inserted by emitProfileNotes()

This patch adds nosantize metadata to memory access instructions inserted by gcov emitProfileNotes(), making sanitizers skip these instructions when gcov and sanitizer are used together.

Reviewed By: nickdesaulniers

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

[mlir][python] Allow specifying block arg locations

Currently blocks are always created with UnknownLoc's for their arguments. This
adds an `arg_locs` argument to all block creation APIs, which takes an optional
sequence of locations to use, one per block argument. If no locations are
supplied, the current Location context is used.

Reviewed By: ftynse

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

[NFC][sanitizer] Rename *ThreadRegistry functions

Reviewed By: thurston

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

[mlir][linalg] Only apply masking on xfer_write when needed.

If the input vector sizes are as same as tensor.pad result shape, the
masking is not needed. Otherwise, the masking is needed and the masking
operands should be as same as tensor.empty op.

Reviewed By: dcaballe

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

[hwasan] Fix allocator_interface implementation

__sanitizer_get_current_allocated_bytes had as body, but allocator
caches were not registered to collect stats. It's done by
SizeClassAllocator64LocalCache::Init().

Reviewed By: thurston

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

[mlir][sparse][gpu] fixed typo in CUDA test

Test was printing same result twice

Reviewed By: K-Wu

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

[mlir][linalg] Treat quant dialect type as unsupported in named conversion

Since the tosa-to-linalg conversion does not support the quant dialect type, we can treat it as unsupported instead of crash.  Issue was reported https://github.com/llvm/llvm-project/issues/62367

Reviewed By: springerm

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