Reviewed By: #libc, ldionne

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

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

This patch adds a test that crashes without the fix.

Reviewed By: ymandel

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

Note that the builders are protected by is64Bit().

More fine-grained availibility checks.

Reviewed By: RKSimon

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

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

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

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

Fix -Wunused-variable in release builds

Reviewed By: krasimir

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

This will allow us to improve the diffs for D151400

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

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

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

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

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

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

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

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

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

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

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

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

To allow getting the original stack trace.

Reviewed By: dvyukov

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

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

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

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

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

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

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

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

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

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

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

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

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

This reverts commit b6655137.

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

This reverts commit ee6b08e9.

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

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

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