The COMPILER_RT_HAS_FLOAT16 cmake check is now set per architecture,
which needs to be reflected when building the tests.

Additionally added armhf to the architecture list.

Reviewed By: dim

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

The revision adds LLVM's is constant intrinsic.

Depends on D150643

Reviewed By: Dinistro

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

This change is necessary to set correct EFlags according to the
options (-m*-float and -mabi=) passed to clang when input is assembly.

Note: `-mabi=` is not documented by `as`.
```
$ as --version
GNU assembler (GNU Binutils) 2.40.50.20230316
...
$ as --target-help
LARCH options:
```

But we can see gcc invokes `as` and passes the `-mabi=` option when compiling C or assembly.
```
$ gcc -c a.c -v 2>&1 -msoft-float | grep "as -v"
 as -v -mabi=lp64s -o a.o /tmp/ccFrxzZi.s
$ gcc -c a.s -v 2>&1 -msoft-float | grep "as -v"
 as -v -mabi=lp64s -o a.o a.s
```

Reviewed By: xen0n

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

lp64s is same as lp64d execpt that floating point arguments and return
values are always passed via GPRs or stack which means `UseGPRForFloat`
is always `true` in `CC_LoongArch` for lp64s.

One motivation of this change is to build linux which uses
`-msoft-float` and `-mabi=lp64s` [1].

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/Makefile?h=v6.4-rc1#n49

Reviewed By: xen0n, hev

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

In practice, a Warning on every occurrence is very unpopular, even on a codebase
with clear rules about direct inclusion & moderately good compliance.

This change has various practical effects (in vscode for concreteness):
  - makes the diagnostic decoration less striking (blue vs yellow)
  - makes these diagnostics visually distinct from others when reading
  - causes these diagnostics to sort last in the "problems" view
  - allows these diagnostics to be easily filtered from the "problems" view

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

This alters the lowering of shifts by a constant, so that the type is lowered
to a v1i64 instead of a i64. This helps communicate that the type will live in
a neon register, and can help clean up surrounding code. Note this is only
currently for the scalar shifts of a constant that go through the nodes in
tryCombineShiftImm.

ssra instructions are no longer being recognized in places, but that can be
cleaned up in a followup patch that combines the i64 add into a v1i64 add.

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

Reviewed By: nikic

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

[clang][AST] Print name instead of type when diagnosing uninitialized subobject in constexpr variables

This patch improves the diagnostic on uninitialized subobjects in constexpr variables by modifying the diagnostic message to display the subobject's name instead of its type.

Fixes https://github.com/llvm/llvm-project/issues/58601
Differential Revision: https://reviews.llvm.org/D146358

check plan:  ninja check-llvm-codegen-x86

Reviewed By: arsenm

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

This is for consistency with other dialects.

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

This tries to fill in some missing testing for neon shift intrinsics, and
regenerates the existing tests. See D148309 and D148311.

This is the second part of the below RFC:
https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493



This patch implements a Value class that can be used to carry expression
results in clang-repl. In other words, when we see a top expression
without semi, it will be captured and stored to a Value object. You can
explicitly specify where you want to store the object, like:

```
Value V;
llvm::cantFail(Interp->ParseAndExecute("int x = 42;"));
llvm::cantFail(Interp->ParseAndExecute("x", &V));
```

`V` now stores some useful infomation about `x`, you can get its real
value (42), it's `clang::QualType` or anything interesting.

However, if you don't specify the optional argument, it will be captured
to a local variable, and automatically called `Value::dump`, which is
not implemented yet in this patch.

Signed-off-by: Jun Zhang <jun@junz.org>

This patch is the first part of the below RFC:
https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493



It adds an annotation token which will replace the original EOF token
when we are in the incremental C++ mode. In addition, when we're
parsing an ExprStmt and there's a missing semicolon after the
expression, we set a marker in the annotation token and continue
parsing.

Eventually, we propogate this info in ParseTopLevelStmtDecl and are able
to mark this Decl as something we want to do value printing. Below is a
example:

clang-repl> int x = 42;
clang-repl> x
// `x` is a TopLevelStmtDecl and without a semicolon, we should set
// it's IsSemiMissing bit so we can do something interesting in
// ASTConsumer::HandleTopLevelDecl.

The idea about annotation toke is proposed by Richard Smith, thanks!

Signed-off-by: Jun Zhang <jun@junz.org>

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

llvm-clang-x86_64-expensive-checks-debian will fail after D150436 merged.
The fail occurred in X86, I changed the sort rule in AsmMatcher in Patch D150436, so x86 code will arrive line 633 first(will not affect other targets).
The logic here want to use the order record written in source file to make AsmMatcher to first use AVX instructions, it used field HasPositionOrder.
But the condition here just makes sure one of the compared record is subclass of Instruction and has field HasPositionOrder true, and didn't check another.

(Committing on behalf of @XinWang10 to unblock broken expensive-cjhecks builds)

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

This reverts commit ef47318e.

This patch breaks valid code https://reviews.llvm.org/D149276#4345620

This moves all but one remaining tests which use clang-cl and test
MSVC-specific behaviour into its own subdirectory. `dll_host.cpp` test
is excluded from the move because other tests also depend on its source
file, making it not MSVC-specific.

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

This appears to be a leftover from when these tests were first added in
D62927. Because of this, these tests had never run with `check-asan` or
`check-asan-dynamic`.

I've tested locally that these tests do pass on both i686 MSVC and MinGW
targets. They are disabled for 64-bit though, and I believe no LLVM
buildbots are testing for 32-bit Windows targets.

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

This ports some tests that requires dead stripping or ICF.

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

This ports tests which requires additional link flags.

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

Continuation of D147432 and D147444.

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

This test checks that asan does not intercept user-provided libc
functions, but on Windows the static asan runtime does intercept static
copies of libc functions, so this test is invalid for said environment.
It used to fail from a different linker error, but this no longer
happens with newer WinSDK. Refer to comments on
https://reviews.llvm.org/D149549.

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

Could be slightly smarter in cases that are probably uninteresting.

Alive2: https://alive2.llvm.org/ce/z/rPN1GB
Fixes: https://github.com/llvm/llvm-project/issues/62238



Depends on D150377

Signed-off-by: Jun Zhang <jun@junz.org>

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

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



Signed-off-by: Jun Zhang <jun@junz.org>

The revision adds the LLVM expect and expect.with.probability
intrinsics.

Reviewed By: Dinistro, ftynse

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

There is memory explosion when converting the body or initializer region of a large global variable, e.g. a constant array.

For example, when translating a constant array of 100000 strings:
```
llvm.mlir.global internal constant @cats_strings() {addr_space = 0 : i32, alignment = 16 : i64} : !llvm.array<100000 x ptr<i8>> {
    %0 = llvm.mlir.undef : !llvm.array<100000 x ptr<i8>>
    %1 = llvm.mlir.addressof @om_1 : !llvm.ptr<array<1 x i8>>
    %2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %3 = llvm.insertvalue %2, %0[0] : !llvm.array<100000 x ptr<i8>>
    %4 = llvm.mlir.addressof @om_2 : !llvm.ptr<array<1 x i8>>
    %5 = llvm.getelementptr %4[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %6 = llvm.insertvalue %5, %3[1] : !llvm.array<100000 x ptr<i8>>
    %7 = llvm.mlir.addressof @om_3 : !llvm.ptr<array<1 x i8>>
    %8 = llvm.getelementptr %7[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %9 = llvm.insertvalue %8, %6[2] : !llvm.array<100000 x ptr<i8>>
    %10 = llvm.mlir.addressof @om_4 : !llvm.ptr<array<1 x i8>>
    %11 = llvm.getelementptr %10[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %12 = llvm.insertvalue %11, %9[3] : !llvm.array<100000 x ptr<i8>>

    ... (ignore the remaining part)
}
```

where `@om_1`, `@om_2`, ... are string global constants.

Each time an operation is converted to LLVM, a new constant is created.
When it comes to `llvm.insertvalue`, a new constant array of 100000 elements is created and the old constant array (input) is not destroyed.
This causes memory explosion. We observed that, on a system with 128 GB memory, the translation of 100000 elements got killed due to using up all the memory.
On a system with 64 GB, 65536 elements was enough to cause the translation killed.

This patch fixes the issue by checking generated constants and destroyed them if there is no use.
By the fix, the translation of 100000 elements only takes about 1.6 GB memory, and finishes without any error.

Reviewed By: ftynse, kiranchandramohan

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

Reviewed By: jdoerfert

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

**Summary**

When filling out the LayoutInfo for a structure with the offsets
from DWARF, LLDB fills gaps in the layout by creating unnamed
bitfields and adding them to the AST. If we don't do this correctly
and our layout has overlapping fields, we will hat an assertion
in `clang::CGRecordLowering::lower()`. Specifically, if we have
a derived class with a VTable and a bitfield immediately following
the vtable pointer, we create a layout with overlapping fields.

This is an oversight in some of the previous cleanups done around this
area.

In `D76808`, we prevented LLDB from creating unnamed bitfields if there
was a gap between the last field of a base class and the start of a bitfield
in the derived class.

In `D112697`, we started accounting for the vtable pointer. The intention
there was to make sure the offset bookkeeping accounted for the
existence of a vtable pointer (but we didn't actually want to create
any AST nodes for it). Now that `last_field_info.bit_size` was being
set even for artifical fields, the previous fix `D76808` broke
specifically for cases where the bitfield was the first member of a
derived class with a vtable (this scenario wasn't tested so we didn't
notice it). I.e., we started creating redundant unnamed bitfields for
where the vtable pointer usually sits. This confused the lowering logic
in clang.

This patch adds a condition to `ShouldCreateUnnamedBitfield` which
checks whether the first field in the derived class is a vtable ptr.

**Testing**

* Added API test case

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

[lldb][DWARFASTParserClang][NFC] Extract condition for unnamed bitfield creation into helper function

This patch adds a new private helper
`DWARFASTParserClang::ShouldCreateUnnamedBitfield` which
`ParseSingleMember` whether we should fill the current gap
in a structure layout with unnamed bitfields.

Extracting this logic will allow us to add additional
conditions in upcoming patches without jeoperdizing readability
of `ParseSingleMember`.

We also store some of the boolean conditions in local variables
to make the intent more obvious.

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

Minor cleanup of redundant variable initialization and
if-condition. These are leftovers/oversights from previous
cleanup in this area:
* https://reviews.llvm.org/D72953
* https://reviews.llvm.org/D76808

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

In order to justify some of the special cases we have, we need to
assume that Op/RepOp are non-poison. For the places where this
function is used, if one of these is poison, then the select result
is poison anyway.

Do not assert if the bit width is larger than 64 bits. This case
is currently hidden from the IR layer by other checks, but gets
exposed with future changes.

Address review comment from https://reviews.llvm.org/D148947

This revision modifies the mem2reg interfaces and algorithm to be more
omfortable to use as a pattern. The motivation behind this is that
currently the pattern needs to be applied to the scope op of the region
in which allocators should be promoted. However, a more natural way to
apply the pattern would be to apply it on the allocator directly. This
is not only clearer but easier to parallelize.

This revision changes the mem2reg pattern to operate this way. This
required restraining the interfaces to only mutate IR using
RewriterBase, as the previously used escape hatch is not granular enough
to match on the region that is modified only. This has the unfortunate
cost of preventing batching allocator promotion and making the block
argument adding logic more complex. Because batching no longer made any
sense, I made the internal analyzer/promoter decoupling private again.

This also adds statistics to the mem2reg infrastructure.

Reviewed By: gysit

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

Define intersectWith and unionWith as two complementary ways of
combining KnownBits. The names are chosen for consistency with
ConstantRange.

Deprecate commonBits as a synonym for intersectWith.

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