When setting conditional breakpoints, we currently assume that a call to
UserExpression::Parse() can be cached and resued multiple times. This
may not be true for every user expression. Add a new method so
subclasses of UserExpression can customize if they are parseable or not.
This reverts commit 186db1bcb0096a6af348d7e17866c68fa2004068.
This relands commit 0718c1a8405ac130d72cd3525befed2911618cc7.
The REQUIRES flag in the test that was added only specified that the
machine needed to have the capability to execute the snippet rather than
actually run it with performance counters. This would work with
--dummy-perf-counters, but that is not currently supported in the
subprocess execution mode. So for now, we require the ability to
actually perform measurements to prevent test failures in configurations
that don't have libpfm or access to performance counters.
These error messages are written in a way that makes sense to an lldb
developer, but not to an end user who asks lldb to run on a compressed
corefile or whatever. Simplfy the messages.
These options select different link modes (note: -shared -static can be
used together for musl and mingw). It makes sense to place them
together, which enables some simplification. The relevant ld options
are now consistently placed after -m, similar to GCC.
While here, suppress -Wunused-command-line-argument warning when -shared
-rdynamic are used together (introduced by commit
291f4a00232b5742940d67e2ecf9168631251317). It can be argued either way
whether the warning is justified (in ELF linkers --export-dynamic
functionality is subsumed by -shared), but it is not useful (users can
do -Wl,--export-dynamic, bypassing the driver diagnostic).
[X86]: Enable custom lowering for fabs.v8f16 on AVX
Currently, custom lowering of fabs.v8f16 requires AVX512FP16, which is
too restrictive. For v8f16 fabs lowering, no instructions in AVX512FP16
are needed. Without the fix, horribly inefficient code is generated
without AVX512FP16. Note instcombiner generates calls to intrinsics
@llvm.fabs.v8f16 when simplifyping AND <8 x half> operations.
Consistently add `branch_weights` metadata in any condition branch
created by `LoopVectorize.cpp`:
- Will only add metadata if the original loop-latch branch had metadata
assigned.
- Most checks should rarely trigger so I am using a 127:1 ratio.
- For the middle block we assume an equal distribution of modulo
results.
Add initial support for DIExpression in LLVM dialect.
Similar to LLVM IR, DI Expression is encoded as a list of uint64. The
difference is that LLVM IR has helpers for understanding the expression
(e.g. for verification and pretty printing), whereas the current support
added by this PR treats the expression elements as opaque.
This patch fixes:
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:609:23:
error: 'describe' overrides a member function but is not marked
'override' [-Werror,-Winconsistent-missing-override]
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:627:23:
error: 'describe' overrides a member function but is not marked
'override' [-Werror,-Winconsistent-missing-override]
This reverts commit 0718c1a8405ac130d72cd3525befed2911618cc7.
The test doesn't have the correct requires string apparently because it
attempts to run on all the buildbots. Reverting until I have time to fix
the test and reland it.
This patch makes it so that specifying an invalid value for
CMAKE_BUILD_TYPE is a fatal error. Having this simply as a warning has
caused me (and probably others) a decent amount of headache. The check
was present before, but was proposed to be modified to a warning in
https://github.com/llvm/llvm-project/issues/60975 and changed to a
warning in c75dbeda15c10424910ddc83a9ff7669776c19ac. This patch
reenables that behavior to hopefully reduce frustration for people
building LLVM in the common case while still allowing for alternative
build types to be setup without needing to perform source modification
through the addition of a CMake flag.
I made a typo at some point while doing the subprocess implementation,
trying to pop RIP from the stack. For whatever reason, this ends up as
popq %rax after being JITed, which means we aren't properly preserving
the value of %rdi.
Regression test added.
This fixes#72188.
This change adds the image used by the self-hosted Github Actions
builders.
In an attempt to make the transition simple, all of the different images
share as much of the same state as possible, including packages, users,
etc... This results in bigger images, but that shouldn't be a problem.
That said, the refactorings caused the buildkite image to shrink by 100
MB.
This change also renames all of the packages for consistency. Bots will
have to be changed to use the new package names eventually.
Again, docker-compose was used as the source of truth for defining
argument.
I have already pushed example images to ghcr.io/libcxx/<name>:testing
The checker now displays one combined note tag for errno-related and
"case"-related notes. Previous functions in the errno-modeling part that
were used for construction of note tags are removed. The note tag added
by StdLibraryFunctionsChecker contains the code to display the note tag
for 'errno' (this was done previously by these removed functions).
Let `llvm.launder.invariant.group` intrinsic as well as instructions
operating on memory addresses, whose invariance may be broken by the
intrinsic, to be rewritten.
Fixes: https://github.com/llvm/llvm-project/issues/72035.
Both options do not affect the AST content that is serialized into the PCM. This
commit includes the following changes:
1.) Mark `-fvisibility={}` and `-ftype-visibility={}` as benign options.That
means they are no longer considered part of the module hash, which can
reduce the number of module variants.
2.) Add a test to verify the generated LLVM IR is not affected by the default
visibiliy mode in the module.
3.) Add a test to clang-scan-deps to ensure only one module is build, even if
the above mentioned options are used.
This fixes rdar://118246054.
For the following testcase:
undef %1.sub1:sgpr_96 = COPY undef %0:sgpr_32
%3:vgpr_32 = V_LSHL_ADD_U32_e64 %1.sub1:sgpr_96, ...
GCNRewritePartialRegUses produced:
%4:vgpr_32 = COPY undef %1:sgpr_32
dead %2:vgpr_32 = V_LSHL_ADD_U32_e64 %4, ...
Register class for %4 is incorrect: there should be sgpr_32 instead of
vgpr_32 because the original %1 had scalar regclass. This patch fixes
that.
Note that GCNRewritePartialRegUses pass isn't enabled by default yet.
operand.
Need to copy the submask not to the very first part of the common
extractelements vector mask, but to the proper one to avoid wrong code
emission.
None of the in-tree implementations have different behaviour for
physical vs virtual registers, and it seems would work equally well if
used with virtual registers. As such, perhaps it's simplest to just drop
that part of the doc comment.
This hook is called by the target-independent implementation of
TargetInstrInfo::describeLoadedValue. I've opted to test it via a C++
unit test, which although fiddly to set up seems the right way to test a
function with such clear intended semantics (rather than testing the
impact indirectly).
isAddImmediate will never recognise ADDIW as an add immediate which I
_think_ is conservatively correct, as the caller may not understand its
semantics vs ADDI.
Note that although the doc comment for isAddImmediate specifies its
behaviour solely in terms of physical registers, none of the current
in-tree implementations (including this one) bail out on virtual
registers (see #72357).
