llvm-undname used to put '\x' in front of every pair of nibbles, but
u"\xD7\xFF" produces a string with 6 bytes: \xD7 \0 \xFF \0 (and \0\0). Correct
for a single character (plus terminating \0) is u\xD7FF instead.
Now, wchar_t, char16_t, and char32_t strings roundtrip from source to
clang-cl (and cl.exe) and then llvm-undname.
(...at least as long as it's not a string like L"\xD7FF" L"foo" which
gets demangled as L"\xD7FFfoo", where the compiler then considers the
"f" as part of the hex escape. That seems ok.)
Also add a comment saying that the "almost-valid" char32_t string I
added in my last commit is actually produced by compilers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358857 91177308-0d34-0410-b5e6-96231b3b80d8
If a unsigned with all 4 bytes non-0 was passed to outputHex(), there
were two off-by-ones in it:
- Both MaxPos and Pos left space for the final \0, which left the buffer
one byte to small. Set MaxPos to 16 instead of 15 to fix.
- The `assert(Pos >= 0);` was after a `Pos--`, move it up one line.
Since valid Unicode codepoints are <= 0x10ffff, this could never really
happen in practice.
Found by oss-fuzz.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358856 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for uadd_sat and friends to ConstantRange, so we can
handle uadd.sat and friends in LVI. The implementation is forwarding
to the corresponding APInt methods with appropriate bounds.
One thing worth pointing out here is that the handling of wrapping
ranges is not maximally accurate. A simple example is that adding 0
to a wrapped range will return a full range, rather than the original
wrapped range. The tests also only check that the non-wrapping
envelope is correct and minimal.
Differential Revision: https://reviews.llvm.org/D60946
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358855 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantRanges have an annoying special case: If upper and lower are
the same, it can be either an empty or a full set. When constructing
constant ranges nearly always a full set is intended, but this still
requires an explicit check in many places.
This revision adds a getNonEmpty() constructor that disambiguates this
case: If upper and lower are the same, a full set is created.
Differential Revision: https://reviews.llvm.org/D60947
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358854 91177308-0d34-0410-b5e6-96231b3b80d8
This does two main things, firstly adding some at least basic addressing modes
for i64 types, and secondly treats floats and doubles sensibly when there is no
fpu. The floating point change can help codesize in some cases, especially with
D60294.
Most backends seems to not consider the exact VT in isLegalAddressingMode,
instead switching on type size. That is now what this does when the target does
not have an fpu (as the float data will be loaded using LDR's). i64's currently
use the address range of an LDRD (even though they may be legalised and loaded
with an LDR). This is at least better than marking them all as illegal
addressing modes.
I have not attempted to do much with vectors yet. That will need changing once
MVE is added.
Differential Revision: https://reviews.llvm.org/D60677
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358845 91177308-0d34-0410-b5e6-96231b3b80d8
The error check required FDEs to refer to the most recent CIE, but the eh-frame
spec allows them to refer to any previously seen CIE. This patch removes the
offending check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358840 91177308-0d34-0410-b5e6-96231b3b80d8
ClangdLSPServer and clangd unittests now include Features.inc so we
need to append the target_gen_dir that contains it to their
include_dirs. To do so, we use a public config that's applied to
any target that depends on the features one.
Differential Revision: https://reviews.llvm.org/D60919
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358837 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't assert when a string looks like a u32 string to the heuristic
but doesn't have a length that's 0 mod 4. Instead, classify those
as u16 with embedded \0 chars. Found by oss-fuzz.
- Print embedded nul bytes as \0 instead of \x00.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358835 91177308-0d34-0410-b5e6-96231b3b80d8
Knowing the address/symbolnum field values makes it easier to identify the
unsupported relocation, and provides enough information for the full bit
pattern of the relocation to be reconstructed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358833 91177308-0d34-0410-b5e6-96231b3b80d8
The extra information here will be helpful in diagnosing errors, like the
ones currently occuring on the PPC big-endian bots. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358826 91177308-0d34-0410-b5e6-96231b3b80d8
This should prevent spurious JITLink unit test failures for builds that do not
support the target(s) required by the tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358825 91177308-0d34-0410-b5e6-96231b3b80d8
DynamicLibrarySearchGenerator::GetForCurrentProcess now takes a char (the global
prefix) rather than a DataLayout reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358820 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
JITLink is a jit-linker that performs the same high-level task as RuntimeDyld:
it parses relocatable object files and makes their contents runnable in a target
process.
JITLink aims to improve on RuntimeDyld in several ways:
(1) A clear design intended to maximize code-sharing while minimizing coupling.
RuntimeDyld has been developed in an ad-hoc fashion for a number of years and
this had led to intermingling of code for multiple architectures (e.g. in
RuntimeDyldELF::processRelocationRef) in a way that makes the code more
difficult to read, reason about, extend. JITLink is designed to isolate
format and architecture specific code, while still sharing generic code.
(2) Support for native code models.
RuntimeDyld required the use of large code models (where calls to external
functions are made indirectly via registers) for many of platforms due to its
restrictive model for stub generation (one "stub" per symbol). JITLink allows
arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be
added naturally.
(3) Native support for asynchronous linking.
JITLink uses asynchronous calls for symbol resolution and finalization: these
callbacks are passed a continuation function that they must call to complete the
linker's work. This allows for cleaner interoperation with the new concurrent
ORC JIT APIs, while still being easily implementable in synchronous style if
asynchrony is not needed.
To maximise sharing, the design has a hierarchy of common code:
(1) Generic atom-graph data structure and algorithms (e.g. dead stripping and
| memory allocation) that are intended to be shared by all architectures.
|
+ -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to
| atom-graph parsing.
|
+ -- (3) Architecture specific code that uses (1) and (2). E.g.
JITLinkerMachO_x86_64, which adds x86-64 specific relocation
support to (2) to build and patch up the atom graph.
To support asynchronous symbol resolution and finalization, the callbacks for
these operations take continuations as arguments:
using JITLinkAsyncLookupContinuation =
std::function<void(Expected<AsyncLookupResult> LR)>;
using JITLinkAsyncLookupFunction =
std::function<void(const DenseSet<StringRef> &Symbols,
JITLinkAsyncLookupContinuation LookupContinuation)>;
using FinalizeContinuation = std::function<void(Error)>;
virtual void finalizeAsync(FinalizeContinuation OnFinalize);
In addition to its headline features, JITLink also makes other improvements:
- Dead stripping support: symbols that are not used (e.g. redundant ODR
definitions) are discarded, and take up no memory in the target process
(In contrast, RuntimeDyld supported pointer equality for weak definitions,
but the redundant definitions stayed resident in memory).
- Improved exception handling support. JITLink provides a much more extensive
eh-frame parser than RuntimeDyld, and is able to correctly fix up many
eh-frame sections that RuntimeDyld currently (silently) fails on.
- More extensive validation and error handling throughout.
This initial patch supports linking MachO/x86-64 only. Work on support for
other architectures and formats will happen in-tree.
Differential Revision: https://reviews.llvm.org/D58704
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358818 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If you pass two 1024 bit vectors in IR with AVX2 on Windows 64. Both vectors will be split in four 256 bit pieces. The four pieces of the first argument will be passed indirectly using 4 gprs. The second argument will get passed via pointers in memory.
The PartOffsets stored for the second argument are all in terms of its original 1024 bit size. So the PartOffsets for each piece are 32 bytes apart. So if we consider it for copy elision we'll only load an 8 byte pointer, but we'll move the address 32 bytes. The stack object size we create for the first part is probably wrong too.
This issue was encountered by ISPC. I'm working on getting a reduce test case, but wanted to go ahead and get feedback on the fix.
Reviewers: rnk
Reviewed By: rnk
Subscribers: dbabokin, llvm-commits, hiraditya
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60801
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358817 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Teach CorrelatedValuePropagation to also handle sub instructions in addition to add. Relatively simple since makeGuaranteedNoWrapRegion already understood sub instructions. Only subtle change is which range is passed as "Other" to that function, since sub isn't commutative.
Note that CorrelatedValuePropagation::processAddSub is still hidden behind a default-off flag as IndVarSimplify hasn't yet been fixed to strip the added nsw/nuw flags and causes a miscompile. (PR31181)
Reviewers: sanjoy, apilipenko, nikic
Reviewed By: nikic
Subscribers: hiraditya, jfb, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60036
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358816 91177308-0d34-0410-b5e6-96231b3b80d8
This is very minor issue. The returned section index is only used by
DWARFDebugLine as an llvm::upper_bound input and the use case shouldn't
cause any behavioral change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358814 91177308-0d34-0410-b5e6-96231b3b80d8
Fix for https://bugs.llvm.org/show_bug.cgi?id=41477. On the x32 ABI
with stack probing a dynamic alloca will result in a WIN_ALLOCA_32
with a 32-bit size. The current implementation tries to copy it into
RAX, resulting in a physreg copy error. Fix this by copying to EAX
instead. Also fix incorrect opcodes or registers used in subs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358807 91177308-0d34-0410-b5e6-96231b3b80d8
This was caught by UBSAN
tools/llvm-objdump/X86/macho-disassembly-g-dsym.test
tools/llvm-objdump/X86/hex-displacement.test
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358806 91177308-0d34-0410-b5e6-96231b3b80d8
The MOVZX doesn't require an immediate to be encoded at all. Though it does use
a 2 byte opcode so its the same size as a 1 byte immediate. But it has a
separate source and dest register so can help avoid copies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358805 91177308-0d34-0410-b5e6-96231b3b80d8
There's one slight regression in here because we don't check that the immediate
already allowed movzx before the shift. I'll fix that next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358804 91177308-0d34-0410-b5e6-96231b3b80d8
Nico Weber