CodeRegion's were previously passed as Value*, but then immediately
upcast to BasicBlock. Let's keep the type information around until the
use cases for non-BasicBlock code regions actually materialize.
Attempt to improve tests by synchronously waiting for breakpoints to
resolve. Not sure if it will fix all the tests but I think it should
make the tests more stable
Microsoft helpfully defines `THIS` to `void` in two different platform
SDK headers, at least one of which is reachable via <Windows.h>. We have
a user who ran into a build because of `THIS` unfortunate macro name
collision.
Rename the members to better match our naming conventions.
Fixes#142186
Move code to get the index of a predecessor and successor to helpers in
VPBlockBase, to avoid duplication and enable future reuse.
Split off from https://github.com/llvm/llvm-project/pull/140409.
This introduces a way detect the libstdc++ version, use that to enable
workarounds.
The version is cached.
This should make it easier in the future to find and remove these hacks.
I did not find the need for enabling a hack between or after specific
versions, so it's left as a future exercise.
We can extend this fature to other libraries as the need arise.
To test the infrastructure added in
https://github.com/llvm/llvm-project/pull/131836 in would be nice to
confirm that we can reconstruct all kinds of demangled names. The
libcxxabi test-suite already has all those test-cases.
This patch copies those test-cases (taken from
`libcxxabi/test/test_demangle.pass.cpp`), reconstructs the name like
LLDB would when showing backtraces, and confirms that all demangled
names can be fully reconstructed.
Two open questions:
1. Do we really want a copy of all those test-cases in LLDB? It's
unlikely to be kept in sync with the demangler test-suite. It includes
30,000+ test-cases
2. Do we want to turn the
`GetDemangledBasename`/`GetDemangledScope`/etc. into public APIs (e.g.,
on `TrackingOutputBuffer`) so that we can use the exact same method of
extraction in the tests?
The ABI bump to adopt the conforming ABI v1 std::pair implementation did
not end up happening for FreeBSD 14, and instead this diff was reverted
downstream in FreeBSD[1]. Align the upstream ABI config with FreeBSD's
actual ABI.
[1] ce4f1f49e036 ("Revert commit 6255157d24 from llvm-project (by
Dimitry Andric):")
This reverts commit 6255157d24.
Refactor code revolving source objects such that most logics will be
reused.
The main change is to expose a single `CreateSource(addr, target)` that
can return either a normal or an assembly source object, and call
`ShouldDisplayAssemblySource()` only from this function instead of
multiple places across the code.
Other functions can use `source.IsAssemblySource()` in order to check
which type the source is.
If ValueTracking can guarantee non-NaN and non-INF and the `nsz`
fast-math flag is set, we can simplify X * 0.0 ==> 0.0.
https://alive2.llvm.org/ce/z/XacRQZ
After seeing the bug that #142185 fixed, I thought it might be a good
idea to start verifying that nodes are formed correctly.
This patch introduces the verifyTargetNode function and adds these
opcodes. More opcodes can be added in later patches.
Note: This relands #134985 with a fix. Original PR resulted in test fail
for msan builds.
Fix: Initialize MipsSubtarget::ProcImpl to ProcImpl::CPU::Others
[MIPS] Reland Add FeatureMSA to i6400 and i6500 cores (#134985)
- Enable 'FeatureMSA' for MIPS i6400 and i6500 cpu.
- Enable -mmsa option if mcpu is set to either i6400 or i6500
- added clang driver test to validate msa feature
- added llvm codegen test to validate msa instructions for cpu i6500 and
i6400
MIPS i6400 and i6500 cores implements and enables MSA (MIPS SIMD
ARCHITECTURE) by default.
Users sometimes forget about configuration they've placed in the user
config file, or an ancestor directory of their project.
Logging the paths of loaded config files by default (without
--log=verbose) surfaces more readily where clangd is getting its
configuration from.
When packaging LLVM we've seen arbitrary tests fail.
It happened sporadically and most of the times the test
do work if they are run a second time on the next day.
The tests themselves were always different and we didn't
know ahead of time which ones we wanted to re-run.
That's we filter-out a lot of `libomp` and `libarcher` tests [1].
This change allows us to set
`LIT_OPTS="--max-retries-per-test=12"`
when running any "check-XXX" build target. Then any lit test
will at most be re-run 12 times, unless there's an `ALLOW_RETRIES:`
in one of the test scripts that's specifying a different value
than `12`. `12` is just an example here, any positive integer
will work.
Please note, that this only adds the possibility to re-run
lit tests. It does not actually do it until the caller specifies
`--max-retries-per-test=<POSITIVE_INT>` either on a call to `lit` or
in `LIT_OPTS`.
Also note, that one can still use `ALLOW_RETRIES:` in test scripts
and it will always rule over `--max-retries-per-test`. When
`--max-retries-per-test` is set too low, but the
`config.test_retry_attempts`
is high enough, it works as well.
Any option in the list below overrules its predecessor:
* `--max-retries-per-test`
* `config.test_retry_attempts`
* `ALLOW_RETRIES` keyword
From the above options to re-run tests, `--max-retries-per-test` is the
only one that doesn't require a change in the test scripts or the test
config.
[1]:
https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_2326
Downstream PR to make use of the `--max-retries-per-test` option:
https://src.fedoraproject.org/rpms/llvm/pull-request/434
Downstream ticket: https://issues.redhat.com/browse/LLVM-145
The check was meant to check `IgnoreProperties` works as expected but
operated on the wrong operation.
Co-authored-by: Aviad Cohen <aviad.cohen2@mobileye.com>
