By creating the header and latch blocks up front and adding blocks and
recipes in between those 2 blocks we ensure that the entry and exits of
the plan remain valid throughout construction.
In order to avoid test changes and keep printing of the plans the same,
we use the new header block instead of creating a new block on the first
iteration of the loop traversing the original loop.
We also fold the latch into its predecessor.
This is a follow up to a post-commit suggestion in D114586.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D115793
This is similar to what we have already done to some other tests.
See D102643, D102710, D102754.
Differential Revision: https://reviews.llvm.org/D116108
dwarfgen::Generator cannot be created if there is no asm backend for a
target. For example, if the default target triple is nvptx-nvidia-cuda,
some tests fail even after D98400, which added checks for most cases.
This patch extends the approach to the remaining cases.
Differential Revision: https://reviews.llvm.org/D116107
If Generator::create() returns an error, tests should fail gracefully
and report the cause, for example:
[ RUN ] DebugLineBasicFixture.ParserSkipsCorrectly
.../llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp:47: Failure
Value of: llvm::detail::TakeExpected(ExpectedGenerator)
Expected: succeeded
Actual: failed (no asm backend for target nvptx64-nvidia-cuda)
Differential Revision: https://reviews.llvm.org/D116106
As reames mentioned on related reviews, we don't need the nocapture
requirement here. First of all, from an API perspective, this is
not something that MemoryLocation::getForDest() should be checking
in the first place, because it does not affect which memory this
particular call can access; it's an orthogonal concern that should
be handled by the caller if necessary.
However, for both of the motivating users in DSE and InstCombine,
we don't need the nocapture requirement, because the capture can
either be purely local to the call (a pointer identity check that
is irrelevant to us), be part of the return value (which we check
is unused), or be written in the dest location, which we have
determined to be dead.
This allows us to remove the special handling for libcalls as well.
Differential Revision: https://reviews.llvm.org/D116148
This patch implements __builtin_reduce_xor as specified in D111529.
Reviewed By: fhahn, aaron.ballman
Differential Revision: https://reviews.llvm.org/D115231
It is not necessary to explicitly check which attributes are
present, and only add those to the builder. We can simply list
all attributes that need to be stripped and remove them
unconditionally. This also allows us to use some nicer APIs that
don't require mucking about with attribute list indices.
The areFunctionArgsABICompatible() hook currently accepts a list of
pointer arguments, though what we're actually interested in is the
ABI compatibility after these pointer arguments have been converted
into value arguments.
This means that a) the current API is incompatible with opaque
pointers (because it requires inspection of pointee types) and
b) it can only be used in the specific context of ArgPromotion.
I would like to reuse the API when inspecting calls during inlining.
This patch converts it into an areTypesABICompatible() hook, which
accepts a list of types. This makes the method more generally usable,
and compatible with opaque pointers from an API perspective (the
actual usage in ArgPromotion/Attributor is still incompatible,
I'll follow up on that in separate patches).
Differential Revision: https://reviews.llvm.org/D116031
Version 2 of 'main bin spec' LC_NOTE allows for the specification
of a slide of where the binary is loaded in the corefile virtual
address space. It also adds a (currently unused) platform field
for the main binary.
Some corefile creators will only have a UUID and an offset to be
applied to the binary.
Changed TestFirmwareCorefiles.py to test this new form of
'main bin spec' with a slide, and also to run on both x86_64
and arm64 macOS systems.
Differential Revision: https://reviews.llvm.org/D116094
rdar://85938455
This commit adds two test about template class instantiation in
transitively imported module. They are used as pre-commit tests for
successive patches.
Differential Revision: https://reviews.llvm.org/D116097
Eliminate a bogus operator== overload.
Also, check more intermediate steps in the logic we're checking here.
Some of this simplification is possible only now that we've implemented
more of <ranges>.
Differential Revision: https://reviews.llvm.org/D116002
Move the handling of brace wrapping after => from unwrapped line
parser to token annotator and clean up the parser.
Differential Revision: https://reviews.llvm.org/D115967
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D115570
Reland integrates build fixes & further review suggestions.
Thanks to @zturner for the initial S_OBJNAME patch!
Differential Revision: https://reviews.llvm.org/D43002
Also revert all subsequent fixes:
- abd1cbf5e5 [Clang] Disable debug-info-objname.cpp test on Unix until I sort out the issue.
- 00ec441253 [Clang] debug-info-objname.cpp test: explictly encode a x86 target when using %clang_cl to avoid falling back to a native CPU triple.
- cd407f6e52 [Clang] Fix build by restricting debug-info-objname.cpp test to x86.
If %{exec} sets "--env PATH=single-dir", the directory containing
bash and related shell utils is omitted from the path, which means
that most shell scripts would fail.
(Setting PATH is needed for DLL builds on Windows; PATH fills the same
role as e.g. LD_LIBRARY_PATH on Linux.)
This condition is missed in the current test, because the executor
run.py first resolves the executable to run using the original path,
then invokes that executable with an environment with a restricted
path. Thus the executor is able to run bash, but that bash is then
unable to run further shell commands (other than bash builtins).
Extend the test from "bash --version" to "bash -c 'bash --version'".
This correctly identifies the executor-has-no-bash condition in the
current Windows CI configs, allowing removing 6 cases of
LIBCXX-WINDOWS-FIXME.
Another longterm fix would be to extend run.py with an option like
"--env-prepend PATH=dir", to allow keeping the current path while
adding a directory to it.
Differential Revision: https://reviews.llvm.org/D116117
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.
This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.
Differential Revision: https://reviews.llvm.org/D116109
This allows cross-testing (by setting LIBCXX_EXECUTOR to point
to ssh.py) without making an entirely new test config file.
Implicitly, this also fixes quoting of the python executable name
(which is quoted in test/CMakeLists.txt).
Differential Revision: https://reviews.llvm.org/D115398
The current code makes the assumption that equality
comparison can be performed with a word comparison
instruction. While this is true if the entire 64-bit
results are used, it does not generally work. It is
possible that the low order words and high order
words produce different results and a user of only
one will get the wrong result.
This patch adds an and of the result words so that
each word has the result of the comparison of the
entire doubleword that contains it.
Differential revision: https://reviews.llvm.org/D115678
Commit 150681f increases
cost of producing MMA types (vector pair and quad).
However, it increases the cost for getUserCost() which is
used in unrolling. As a result, loops that contain these
types already (from the user code) cannot be unrolled
(even with the user's unroll pragma). This was an unintended
sideeffect. Reverting that portion of the commit to allow
unrolling such loops.
Differential revision: https://reviews.llvm.org/D115424
Run performance tests in denormal and normal ranges separately and show more detailed results.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D116112
The new tsan runtime has 2x more compact shadow.
Adjust shadow ranges accordingly.
Depends on D112603.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D113751
If there are multiple processes, it's hard to understand
what output comes from what process.
VReport prepends pid to the output. Use it.
Depends on D113982.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D113983
Florian Hahn