These instructions actually use a 512-byte location, where bytes 464-511 are ignored.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D86942
The sysctlnametomib function is called from __tsan::Initialize via
__sanitizer::internal_sysctlbyname (see stack trace below). This results
in a fatal error since sysctlnametomib has not been intercepted yet.
This patch allows internal_sysctlbyname to be called before
__tsan::Initialize() has completed. On FreeBSD >= 1300045 sysctlbyname()
is a real syscall, but for older versions it calls sysctlnametomib()
followed by sysctl(). To avoid calling the intercepted version, look up
the real sysctlnametomib() followed by internal_sysctl() if the
syscall is not available.
This reduces check-sanitizer failures from 62 to 11 for me.
==34433==FATAL: ThreadSanitizer: failed to intercept sysctlnametomib
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:51
name=0x7fffffffce10, namelenp=0x7fffffffce08)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:7908
oldp=0x7fffffffcf2c, oldlenp=0x7fffffffcf20, newp=0x0, newlen=0)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:803
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:2152
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:367
fname=0x21c731 "readlink", pc=34366042556)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:255
bufsiz=1024)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:7151
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D85292
On -O0, i1 strict_fsetcc will be promoted to i32. We don't handle that
in TD patterns. This patch fills logic in PPCISelDAGToDAG to handle more
cases.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D86595
This patch replaces three different pre-existing implementations of
__div[sdt]f3 LibCalls with a generic one - like it is already done for
many other LibCalls.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85031
This patch adds the td instruction definitions of the xvcvspbf16 and xvcvbf16spn
instructions, along with their respective MC tests.
Differential Revision: https://reviews.llvm.org/D86794
Conformance checking of the shapes of the operands of
array expressions can't, of course, always be done at
compilation time; but when the shapes are known and
nonconformable, we should catch the errors that we can.
Differential Revision: https://reviews.llvm.org/D86887
This reverts commit e9d9a61208.
This patch was previously revert by 04879086b4
with the reapplication being done after breaking the assert used to
ensure SP is always 16-byte aligned, which is a requirement of the AAPCS.
For extra context the latest patch caused runtime failures when
building with "-march=armv8-a+sve -mllvm -aarch64-sve-vector-bits-min=256".
Unmerges have the same fundamental problem as G_TRUNC, and G_TRUNC
could be implemented in terms of G_UNMERGE_VALUES. Reducing the number
of elements in unmerge results ends up producing the original unmerge
type profile, so the artifact combiner needs to eliminate the
intermediate illegal registers. This avoids infinite looping in the
legalizer in a future change.
Assuming an unmerge has each result unmerged the same way, this ends
up producing a new unmerge of the source for every definition. I'm not
sure if the artifact combiner should either insert temporary merges
here and erase the original merge, or if the combiner should look at
uses from defs rather than defs from uses for unmerges.
In a few cases this regresses from using 16-bit shifts for 8-bit
values to using 32-bit shifts, but I think these can be legalized
later (the other legalization rules don't try very hard to use 16-bit
shifts either).
Currently the dbg_value ends up in the relaxed branch block. A future
commit will push the dbg_value out of this block, and I'm not sure how
to coax the IR into producing the same MIR at the relevant point.
This patch adds the initial toolchain for z/OS that will set some defaults. In subsequent patches, we plan to add support to use the system linker and assembler.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D86707
Loop Idiom Recognize Pass (LIRP) attempts to transform loops with subscripted arrays
into memcpy/memset function calls. In some particular situation, this transformation
introduces negative impacts. For example: https://bugs.llvm.org/show_bug.cgi?id=47300
This patch will enable users to disable a particular part of the transformation, while
he/she can still enjoy the benefit brought about by the rest of LIRP. The default
behavior stays unchanged: no part of LIRP is disabled by default.
Reviewed By: etiotto (Ettore Tiotto)
Differential Revision: https://reviews.llvm.org/D86262
We have Error.cpp/.h which contains some code for working with error codes.
In fact we use Error/Expected<> almost everywhere already and we can get rid
of these files.
Note: a few places in the code used readobj specific error codes,
e.g. `return readobj_error::unknown_symbol`. But these codes are never really used,
i.e. the code checks the fact of a success/error call only.
So I've changes them to `return inconvertibleErrorCode()` for now.
It seems that these places probably should be converted to use `Error`/`Expected<>`.
Differential revision: https://reviews.llvm.org/D86772
This relands e9a3d1a401 which was originally
missing linking LLVMSupport into LLMVFileCheck which broke the SHARED_LIBS build.
Original summary:
The actual FileCheck logic seems to be implemented in LLVMSupport. I don't see a
good reason for having FileCheck implemented there as it has a very specific use
while LLVMSupport is a dependency of pretty much every LLVM tool there is. In
fact, the only use of FileCheck I could find (outside the FileCheck tool and the
FileCheck unit test) is a single call in GISelMITest.h.
This moves the FileCheck logic to its own LLVMFileCheck library. This way only
FileCheck and the GlobalISelTests now have a dependency on this code.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86344
Function Sema::isOpenMPGlobalCapturedDecl() has a parameter `unsigned Level`,
but use `Level >= 0` as the condition of `while`, thus cause an infinite loop.
Fix by changing the loop condition to `Level > 0`.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D86858
This patch adds tests for dumping the .debug_line_str section. The
dumper of the debug_line_str section is able to write nonprintable
strings as escaped chars while the dumper of the debug_str and
debug_str.dwo sections cannot. I will fix them and add tests for them
in a follow-up patch.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86916
Fix compilation of libcxx when using -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY. Target `cxx_external_threads` gets linked to `cxx-headers` to include all needed headers and flags.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D86773
`amdgpu-elf-definitions.test` is a file that tests
`Format`, 'OS/ABI' and 'Machine' fields printed for EM_AMDGPU.
It uses a precompiled object.
It is not needed to have it, because:
1) We already test formats in `file-header-format.test` + `llvm/unittests/Object/ELFObjectFileTest.cpp`.
2) We test 'OS/ABI' in `file-header-os-abi.test` for all possible values.
3) We test machine types in `file-header-machine-types.test`
In addition we have `amdgpu-elf-headers.test` which tests EM_AMDGPU specific flags. I.e.
it also tests the fact that llvm-readobj/elf are able to dump such objects.
This patch removes the test case and the corresponding binary.
Differential revision: https://reviews.llvm.org/D86774
This replaces `reportError` calls with `reportUniqueWarning` and improves testing
for the code that is related to stack sizes dumping.
Differential revision: https://reviews.llvm.org/D86783
By using optionals, we no longer have to check the validity of types that we
get from a lookup. This way, the definition of the summaries have a declarative
form, there are no superflous conditions in the source code.
Differential Revision: https://reviews.llvm.org/D86531
I have fixed up a number of warnings resulting from TypeSize -> uint64_t
casts and calling getVectorNumElements() on scalable vector types. I
think most of the changes are fairly trivial except for those in
DAGTypeLegalizer::SplitVecRes_MLOAD I've tried to ensure we create
the MachineMemoryOperands in a sensible way for scalable vectors.
I have added a CHECK line to the following test:
CodeGen/AArch64/sve-split-load.ll
that ensures no new warnings are added.
Differential Revision: https://reviews.llvm.org/D86697
Continue to heuristically pick the wider of the two operands for
narrowing conversion warnings so that some_char + 1 isn't treated as
being wider than a char, but use the more accurate computation for
tautological comparison warnings.
Differential Revision: https://reviews.llvm.org/D85778
-frewrite-includes.
Remove the special-case (and highly implausible) diagnostic for a
compound token that crosses a file boundary, and instead model that case
the same as a compound token separated by whitespace, so that file
transitions and presumed file transitions behave the same way.
Use of a linebreak between the `(` and `{` in a GNU statement-expression
appears to be too common to include this warning in -Wall -- this occurs
in some Linux kernel headers, for example.
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
MemoryPhis with a single value are correct, but can lead to errors when
updating. Clean up single entry Phis newly added when cloning blocks.
Resolves PR46574.
This patch makes the debug_str section optional. When the debug_str
section exists but doesn't contain anything, yaml2obj will emit a
section header for it.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D86860
This patch add the missing operands to the acc.loop operation. Only the device_type
information is not part of the operation for now.
Reviewed By: rriddle, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D86753
Clients who rely on the Context loading dialects from the global
registry can call `mlir::enableGlobalDialectRegistry(true);` before
creating an MLIRContext
Differential Revision: https://reviews.llvm.org/D86897
Eric Astor