See D151029

Fixes https://github.com/llvm/llvm-project/issues/62856

Reviewed By: jlebar

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

This reverts commit aae8524b, which was
found to cause a few unexpected benchmark performance differences that
need investigation.

Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics.  Set them in name
resolution, and emit them to module files.

Depends on https://reviews.llvm.org/D150159.

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

If a vm.s.x pseudo has an undef passthru operand, then we're free to use
whatever tail policy we want for VL > 1. We previously relaxed the tail
policy for this but only when we could also expand the SEW.
This patch changes it to relax the tail policy even if the SEW can't be
expanded and removes a few more toggles, as well as fully moving the
vmv.s.x logic into getDemanded.

vmv.s.x/vfmv.s.f instructions that only write to the first destination
element can use any SEW greater than or equal to its original SEW,
provided that it's writing to an implicit_def operand where we can
clobber the other lanes.

We were already handling this in needVSETVLI, which meant that when
scanning the instructions from top to bottom we could detect this and
avoid the toggle:

	vsetivli	zero, 4, e64, mf2, ta, ma
	li	a0, 11
	vsetivli	zero, 1, e8, mf8, ta, ma
	vmv.s.x	v0, a0

->
	vsetivli	zero, 4, e64, mf2, ta, ma
	li	a0, 11
	vmv.s.x	v0, a0
The issue that this patch aims to solve is arises when the vmv.s.x is
the first vector instruction in the block and doesn't have any prior
predecessor info:

entry_bb:
	li	a0, 11
	; No previous state here: forced to set VL/VTYPE
	vsetivli	zero, 1, e8, mf8, ta, ma
	vmv.s.x	v0, a0
	vsetivli	zero, 4, e16, mf2, ta, ma
	vmerge.vvm	v8, v9, v8, v0
doLocalPostpass can work backwards from bottom to top and work out if
an earlier vsetvli can be mutated to avoid a toggle. It uses
DemandedFields and getDemanded for this, which previously didn't take
into account the possibility of going to a larger SEW.

A previous patch consolidated the vmv.s.x logic from needVSETVLI logic
into getDemanded, and this patch removes the gate around it so that
doLocalPostpass can now delete vsetvlis like in the scenario below:

entry_bb:
	li	a0, 11
	; Previous vsetivli mutated: second one deleted
	vsetivli	zero, 4, e16, mf2, ta, ma
	vmv.s.x	v0, a0
	vmerge.vvm	v8, v9, v8, v0

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

This patch restructures the logic that checks if vmv.s.x's SEW can be
expanded into getDemandedBits, so that it can be shared by both the
top-to-bottom and bottom-to-top passes.

It adds a third option for SEW in DemandedFields, that's weaker than
demanded but stronger than not demanded, that states that it the new SEW
must be greater than or equal to the current SEW.

Note that we now need to take care of the order of operands in
areCompatibleVTYPEs as the relation is no longer commutative.

A later patch will remove the gating on the bottom-to-top pass
(dolocalPostpass) and another one will relax the demands on the tail
policy further.

This patch uses castAs instead of getAs which will assert if the type doesn't match in SetValueDataBasedOnQualType(clang::Value &, unsigned long long).

Reviewed By: erichkeane

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

This reverts commit 35a00792.

The backend support is not present yet. The intrinsics will crash
the compiler if compiled to assembly or binary.

This reverts commit 0ba41dd3.

vmv.s.x and friends that only write to the first destination element can
use any SEW greater than or equal to its original SEW, provided that
it's writing to an implicit_def operand where we can clobber the other
lanes.

We were already handling this in needVSETVLI, which meant that when
scanning the instructions from top to bottom we could detect this and
avoid the toggle:

```
	vsetivli	zero, 4, e64, mf2, ta, ma
	li	a0, 11
	vsetivli	zero, 1, e8, mf8, ta, ma
	vmv.s.x	v0, a0

->
	vsetivli	zero, 4, e64, mf2, ta, ma
	li	a0, 11
	vmv.s.x	v0, a0

```
The issue that this patch aims to solve is whenever vmv.s.x arises when
the first vector instruction in the block and doesn't have any prior
predecessor info:

```
entry_bb:
	li	a0, 11
	; No previous state here: forced to set VL/VTYPE
	vsetivli	zero, 1, e8, mf8, ta, ma
	vmv.s.x	v0, a0
	vsetivli	zero, 4, e16, mf2, ta, ma
	vmerge.vvm	v8, v9, v8, v0
```

doLocalPostpass can work backwards from bottom to top and work out if
an earlier vsetvli can be mutated to avoid a toggle. It uses
DemandedFields and getDemanded for this, which previously didn't take
into account the possibility of going to a larger SEW.

This patch adds a third option for SEW in DemandedFields, that's weaker
than demanded but stronger than not demanded, that states that it the
new SEW must be greater than or equal to the current SEW.

We can then use this option to move that vmv.s.x specific logic from
needVSETVLI into getDemanded, making it available for both phase 2 and
3, i.e. we can now mutate the earlier vsetivli going from bottom to top:

```
entry_bb:
	li	a0, 11
	; Previous vsetivli mutated: second one deleted
	vsetivli	zero, 4, e16, mf2, ta, ma
	vmv.s.x	v0, a0
	vmerge.vvm	v8, v9, v8, v0
```

Reviewed By: reames

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

This patch uses castAs instead of getAs which will assert if the type doesn't match in HandleRISCVRVVVectorBitsTypeAttr(clang::QualType &, clang::ParsedAttr &, clang::Sema &)

Reviewed By: erichkeane

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

In D148546, I replaced much of the use of llvm::StringView w/
std::string_view.  There's one important semantic difference between the
two:

In most STL containers, end() returns an iterator that refers to one
past the end of the container. But llvm::StringView::end() refers to the
last element.

Expressions such as `&*my_std_string_view.end()` produce the failed
assertion:

  include/c++/v1/__iterator/bounded_iter.h:93: assertion
  __in_bounds(__current_) failed: __bounded_iter::operator*: Attempt to
  dereference an out-of-range iterator

This was caught when copying the recent downstream changes back upstream
in D148566, and is reproducible via:

  $ libcxx/utils/ci/run-buildbot generic-debug-mode

when compiled with clang and clang++. The correct way to get the same
value as before without dereferencing invalid iterators is to prefer
`&*my_std_string_view.rbegin() + 1`.

Fix this downstream so that I might copy it back upstream in D148566.

The other instance of `&*my_std_string_view.end()` that I introduced in
D148546 has been fixed already in D149061.

Reviewed By: ashay-github

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

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
 - a new LanguageFeature enum value for CUDA Fortran
 - driver change to enable that feature for *.cuf and *.CUF source files
 - parse tree representation of CUDA Fortran syntax
 - dumping and unparsing of the parse tree
 - the actual parsers for CUDA Fortran syntax
 - prescanning support for !@CUF and !$CUF
 - basic sanity testing via unparsing and parse tree dumps

... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.

Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.

More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.

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

Fix -u option in dsymutil, to not emit an extra DW_LNE_set_address if the original line table was empty

With dsymutil's -u option, only the accelerator tables should be
updated, but with https://reviews.llvm.org/D150554 the -u option will
still re-generate the line table. If the line table was empty, that is,
it was a dummy line table, with no entries in it, dsymutil will always
generate a line table with a DW_LNE_end_sequence, a funky side effect of
this is that when the line table is re-generated, it will always emit a
DW_LNE_set_address first, which will change the line table total size.
This patch addresses this by making sure that if all the line table has
in it is a DW_LNE_end_sequence, it is the same as a dummy entry.

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

There is no need to specify any `check-prefix` here.

Reviewed By: thieta, kwk

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

Current implementations of x87 80-bit extended precision floating
point interpret 7FFF8000000000000000 as +Inf, not a Nan.  The explicit
MSB in the significand must be set for an infinity.

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

There are places in the runtime, like __kmp_init_indirect_csptr, which
assume these pointers are aligned to sizeof(void*), so make sure we emit
them with the correct alignment.

Fixes #62668

Reviewed By: jlpeyton

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

LLVM_TOOL_LLD_BUILD is a relic of the pre-monorepo times. This causes us to never set COMPILER_RT_HAS_LLD.

Instead, set it from the runtimes build if lld is being built and lld is used as the compiler-rt linker.

Reviewed By: MaskRay

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

The output editing code paths for F and E/D output that handle
IEEE-754 infinities and NaNs fail to check for overflow of the
output field, which should cause the field to be filled with
asterisks instead.  Catch these cases.

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

The last use was removed by:

  commit bb1ea2d6
  Author: Nemanja Ivanovic <nemanja.i.ibm@gmail.com>
  Date:   Mon May 9 08:52:33 2016 +0000

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

This reverts commit 4369de7a.

Fails on Mac OS with "sanitizer_libc.cpp:109:5: error: aliases are not
supported on darwin".

In this patch it is used for the prototype:
  * svptrue_c8 (and _c16/_c32/_c64)

 As described in: https://github.com/ARM-software/acle/pull/257

Patch by: Sander de Smalen <sander.desmalen@arm.com>

Reviewed By: sdesmalen, david-arm

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

When computing the shape of an expression at compilation time as part of
folding an intrinsic function like SIZE(), don't create an expression that
increases a dependence on the presence of an optional dummy argument.

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

Similar to what we do with ConstantRanges, also test 1-bit values
in exhaustive tests, as these often expose special conditions.
This would have exposed the assertion failure fixed in D151788
earlier.

 llvm-project/llvm/lib/Target/RISCV/RISCVISelLowering.cpp:3793:7:
 error: unused variable 'XLenVT' [-Werror,-Wunused-variable]

[X86] X86FixupVectorConstantsPass - use VBROADCASTSS/VBROADCASTSD for integer vector loads on AVX1-only targets

Matches behaviour in lowerBuildVectorAsBroadcast

The CI can no longer run with clang-tidy 16 increment it to version 17.
Whether permanently moving to the latest development version is being
discussed on Discourse.

Depends on D149455

Reviewed By: #libc, ldionne

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

Module require Clang 17, since Clang 16 requires the magic # __FILE__
line. Therefore, if available, use clang-tidy 17 too. This change should
be reverted after LLVM 17 is released.

Reviewed By: #libc, ldionne

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

A slightly different fix is in D144994.

Reviewed By: #libc, ldionne

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

The diagnostic is issued by clang-tidy 17.

This just suppressed the diagnostic. The move operations are non-standard extensions and the class itself is deprecated.

Reviewed By: #libc, ldionne

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

Make `GetVariable` a passthrough function the the underlying value object in `ValueObjectSynthetic`.

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

D111241 added support for extractBits() with zero width. Extend this
to extractBitsAsZExtValue() as well for consistency (in which case
it will always return zero).

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

`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the need for callers to construct a
`ConstString`. I don't expect this change to improve performance, only ergonomics.

This is in support of Alex's effort to replace `ConstString` where appropriate.

There are related `ValueObject` functions that can also be changed, if this is accepted.

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

In the future we intend to add support for many PowerPC-specific intrinsics that ideally will exist in a separate new PPCIntrinsicCall file. But first we need to move definitions to the IntrinsicCall header file to increase code cleanliness and readability and to make code reusable for when we add PPCIntrinsicCall.

Reviewed By: vzakhari

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

This patch uses SCEV to check if a value is uniform across a given VF.

The basic idea is to construct SCEVs where the AddRecs of the loop are
adjusted to reflect the version in the vectorized loop (Step multiplied
by VF). We construct a SCEV for the value of the vector lane 0
(offset 0) compare it to the expressions for lanes 1 to the last vector
lane (VF - 1). If they are equal, consider the expression uniform.

While re-writing expressions, we also need to catch expressions we
cannot determine uniformity (e.g. SCEVUnknown).

Reviewed By: Ayal

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

D135716 introduced -ftrivial-auto-var-init=pattern where supported.
Unfortunately this introduces unwanted memset() for large stack arrays,
as shown by the new tests added for asan and msan (tsan already had this
test).

In general, the problem of compiler-inserted memintrinsic calls
(memset/memcpy/memmove) is not new to compiler-rt, and has been a
problem before.

To avoid introducing unwanted memintrinsic calls, we redefine
memintrinsics as __sanitizer_internal_mem* at the assembly level for
most source files automatically (where sanitizer_common_internal_defs.h
is included).

In few cases, redefining a symbol in this way causes issues for
interceptors, namely the memintrinsic interceptor themselves. For such
source files we have to selectively disable the redefinition.

Other alternatives have been considered, but simply do not work well in
the context of compiler-rt:

	1. Linker --wrap:  this does not work because --wrap only
	   applies to the final link, and would not apply when building
	   sanitizer static libraries.

	2. Changing references to memset() via objcopy:  this may work,
	   but due to the complexities of the build system, introducing
	   such a post-processing step for the right object files (in
	   particular object files defining memset cannot be touched)
	   seems infeasible.

The chosen solution works well (as shown by the tests). Other libraries
have chosen the same solution where nothing else works (see e.g. glibc's
"symbol-hacks.h").

v2:
- Fix ubsan_minimal build where compiler decides to insert
  memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc,
  therefore do not redefine the builtins.
- Fix definition of internal_mem* functions with compilers that want the
  aliased function to already be defined before.
- Fix definition of __sanitizer_internal_mem* functions with compilers
  more pedantic about attribute placement around extern "C".

Reviewed By: vitalybuka, dvyukov

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