The raw CodeView format references strings by "offsets", but it's
confusing what table the offset refers to. In the case of line
number information, it's an offset into a buffer of records,
and an indirection is required to get another offset into a
different table to find the final string. And in the case of
checksum information, there is no indirection, and the offset
refers directly to the location of the string in another buffer.
This would be less confusing if we always just referred to the
strings by their value, and have the library be smart enough
to correctly resolve the offsets on its own from the right
location.
This patch makes that possible. When either reading or writing,
all the user deals with are strings, and the library does the
appropriate translations behind the scenes.
llvm-svn: 302053
llvm-readobj hand rolls some CodeView parsing code for string
tables, so this patch updates it to re-use some of the newly
introduced parsing code in LLVMDebugInfoCodeView.
Differential Revision: https://reviews.llvm.org/D32772
llvm-svn: 302052
I was worried we might replace a mul with a mul+shift even if there were later
uses. Turns out to be unfounded but I'd just as well add an actual test for it.
llvm-svn: 302051
This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses.
Differential Revision: https://reviews.llvm.org/D31630
llvm-svn: 302050
Summary: Do the transform when the carry isn't used. It's a pattern exposed when legalizing large integers.
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32755
llvm-svn: 302047
Adrian requested we create a DWARFVerifier.cpp file to contain all of the DWARF verification stuff. This change simply moves the functionality over into DWARFVerifier.h and DWARFVerifier.cpp, renames the DWARFVerifier methods to start with lower case, and switches DWARFContext.cpp over to using the new functionality.
Differential Revision: https://reviews.llvm.org/D32809
llvm-svn: 302044
This was reverted due to a "missing" file, but in reality
what happened was that I renamed a file, and then due to
a merge conflict both the old file and the new file got
added to the repository. This led to an unused cpp file
being in the repo and not referenced by any CMakeLists.txt
but #including a .h file that wasn't in the repo. In an
even more unfortunate coincidence, CMake didn't report the
unused cpp file because it was in a subdirectory of the
folder with the CMakeLists.txt, and not in the same directory
as any CMakeLists.txt.
The presence of the unused file was then breaking certain
tools that determine file lists by globbing rather than
by what's specified in CMakeLists.txt
In any case, the fix is to just remove the unused file from
the patch set.
llvm-svn: 302042
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Reapplied - this time without changing line endings of existing files.
Differential Revision: https://reviews.llvm.org/D32769
llvm-svn: 302041
Currently several places assume the VAL member is always at least the same size as pVal. In particular for a memcpy in the move assignment operator. While this is a true assumption, it isn't good practice to assume this.
This patch gives the union a name so we can write the memcpy in terms of the union itself. This also adds a similar memcpy to the move constructor where we previously just copied using VAL directly.
This patch is mostly just a mechanical addition of the U in front of VAL and pVAL everywhere. But several constructors had to be modified since we can't directly initializer a field of named union from the initializer list.
Differential Revision: https://reviews.llvm.org/D30629
llvm-svn: 302040
Check to make sure no compile units have the same DW_AT_stmt_list values. Report a verification error if they do.
Differential Revision: https://reviews.llvm.org/D32771
llvm-svn: 302039
delayed diagnostic
This avoids an infinite loop that was uncovered in one of our internal tests
by r301992. The testcase is the most reduced version of that auto-generated
test.
rdar://31962618
llvm-svn: 302037
Allocframe and the following stores on the stack have a latency of 2 cycles
when not in the same packet. This happens because R29 is needed early by the
store instruction. Since one of such stores can be packetized along with
allocframe and use old value of R29, we can assign it 0 cycle latency
while leaving latency of other stores to the default value of 2 cycles.
Patch by Jyotsna Verma.
llvm-svn: 302034
The packetizer needs to convert .cur instruction to its regular form if
the use is not in the same packet as the .cur. The code in the packetizer
handles one type of .cur, which is the vector load case. This patch
updates the packetizer so that it can undo all the .cur instructions.
In the test case, the .cur is the 128B version, but there are also the
post-increment versions.
Patch by Brendon Cahoon.
llvm-svn: 302032
https://reviews.llvm.org/D32807
This patch allows the map modifier 'always' to be separated by the map type (to, from, tofrom) only by a whitespace, rather than strictly by a comma as in current trunk.
llvm-svn: 302031
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Differential Revision: https://reviews.llvm.org/D32769
llvm-svn: 302028
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
llvm-svn: 302027
Summary:
When apps or other libraries link against a library with symbol
versions, the version string is recorded in the import table, and used
at runtime to resolve the symbol back to a library that provides that
version (vaguely like how two-level namespaces work in Mach-O). ld's
--default-symver flag tags every exported symbol with a symbol version
string equal to the library's soname. Using --default-symver means
multiple versions of libLLVM can coexist within the same process, at
least to the extent that they don't try to pass data between each
other's llvms.
As an example, imagine a language like Rust using llvm for CPU codegen,
binding to OpenGL, with Mesa as the OpenGL implementation using llvm for
R600 codegen. With --default-symver Rust and Mesa will resolve their
llvm usage to the version each was linked against, which need not match.
(Other ELF platforms like BSD and Solaris might have similar semantics,
I've not checked.)
This is based on an autoconf version of this patch by Adam Jackson.
This new option can be used to add --default-symver to the linker flags
for libLLVM.so.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30997
llvm-svn: 302026
In a previous patch, a new generic error diagnostic for inconsistent attributes was added.
In this commit I reuse this diagnostic for ns_returns_retained attribute check.
Differential Revision: https://reviews.llvm.org/D32697
llvm-svn: 302024
It is needed to check that the number of operands are 2 when
finding the case of a logic combination, e.g. 'and' of two compares.
Review: Ulrich Weigand
llvm-svn: 302022
- Fixes breakage from commit 5536f.
- Interference with commit 764f3 caused testcase to fail. Reverting
764f3 allows commit 5536f to succeed.
- Generated kernel code was slightly different due to 764f3, which
caused testcase to fail.
llvm-svn: 302021
Fixes PR31789 - When loop-vectorize tries to use these intrinsics for a
non-default address space pointer we fail with a "Calling a function with a
bad singature!" assertion. This patch solves this by adding the 'vector of
pointers' argument as an overloaded type which will determine the address
space.
Differential revision: https://reviews.llvm.org/D31490
llvm-svn: 302018
It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").
rdar://problem/31718115
Differential Revision: https://reviews.llvm.org/D32702
llvm-svn: 302016
Summary:
Currently, loop deletion deletes loop where the only values
that are used outside the loop are loop-invariant.
This patch adds logic to delete loops where the loop is proven to be
never executed (i.e. the only predecessor of the loop preheader has a
constant conditional branch as terminator, and the preheader is not the
taken target). This will remove loops that become dead after
loop-unswitching generates constant conditional branches.
The next steps are:
1. moving the loop deletion implementation to LoopUtils.
2. Add logic in loop-simplifyCFG which will support changing conditional
constant branches to unconditional branches. If loops become unreachable in this
process, they can be removed using `deleteDeadLoop` function.
Reviewers: chandlerc, efriedma, sanjoy, reames
Reviewed by: sanjoy
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32494
llvm-svn: 302015
gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expansion happens in-process
there). We could use make $(wildcard) here, but it seems safer to
explicitly list the files here, just like the normal Makefile.rules
does.
llvm-svn: 302013
This produces warnings that I can't explain in a GCC build:
In file included from ../tools/clang/include/clang/Lex/LexDiagnostic.h:13:0,
from /usr/local/google/home/djasper/llvm/tools/clang/lib/Lex/PTHLexer.cpp:19:
../tools/clang/include/clang/Basic/Diagnostic.h:219:34: warning: ‘clang::DiagnosticsEngine::DiagState::ExtBehavior’ is too small to hold all values of ‘enum class clang::diag::Severity’ [enabled by default]
diag::Severity ExtBehavior : 4; // Map extensions to warnings or errors?
^
While I don't think this warning makes sense, I'd like to get this back to being
warning-free. This only seems to trigger for "enum class".
Reproducer:
https://godbolt.org/g/P2ekVd
llvm-svn: 302012
The "macosx" OS type is still the canonical type. In the future "macos" will
become the canonical OS type (but we will still support "macosx").
rdar://27043820
Differential Revision: https://reviews.llvm.org/D32748
llvm-svn: 302011
Summary: It seems that if we have no context, then it can't possibly be a method. Check that first.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D32708
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302008
The --section-start <name>=<address> needs to be translated into equivalent
linker script commands. There are a couple of problems with the existing
implementation:
- The --section-start with the lowest address is assumed to be at the start
of the map. This assumption is incorrect, we have to iterate through the
SectionStartMap to find the lowest address.
- The addresses in --section-start were being over-aligned when the
sections were marked as PageAlign. This is inconsistent with the use of
SectionStartMap in fixHeaders(), and can cause problems when the PageAlign
causes an "unable to move location counter backward" error when the
--section-start with PageAlign is aligned to an address higher than the next
--section-start. The ld.bfd and ld.gold seem to be more consistent with this
approach but this is not a well specified area.
This change fixes the problems above and also corrects a typo in which
fabricateDefaultCommands() is called with the wrong parameter, it should be
called with AllocateHeader not Config->MaxPageSize.
Differential Revision: https://reviews.llvm.org/D32749
llvm-svn: 302007
Before rL301170 was landed, LLD did not produce correct entries in .gdb_index address area.
Issue was fixed on LLVM DWARF parsers side and was relative to how .debug_ranges
section was scanned. It was main problem of PR32319.
It makes sense to have testcase on LLD size too. This checks that we generate proper values
now, because we do not have any tests for .gdb_index which works with .debug_ranges atm.
Differential revision: https://reviews.llvm.org/D32750
llvm-svn: 302006
Before this change a memory reference identifier had the form:
<STMT>_<ACCESSTYPE><ID>_<MEMREF>, e.g., Stmt_bb9_Write0_MemRef_tmp11
After this change, we use the format:
<STMT>_<ACCESSTYPE><ID>, e.g., Stmt_bb9_Write0
The name of the array that is accessed through a memory reference is not
necessary to uniquely identify a memory reference, but was only added to
provide additional information for debugging. We drop this information now
for the following two reasons:
1) This shortens the names and consequently improves readability
2) This removes a second location where we decide on the name of a scop array,
leaving us only with the location where the actual scop array is created.
Having after 2) only a single location to name scop arrays will allow us to
change the naming convention of scop arrays more easily, which we will do
in a future commit to reduce compilation time.
llvm-svn: 302004
I think this is a false positive in GCC's warning, but nonetheless, we
should try to be warning-free. Smaller reproducer (reproduces with GCC
6.3):
https://godbolt.org/g/cJuO2z
llvm-svn: 302003
Zachary Turner