This was originally reported as a bug with the symptom being "cvdump
crashes when printing an LLD-linked PDB that has an S_FILESTATIC record
in it". After some additional investigation, I determined that this was
a symptom of a larger problem, and in fact the real problem was in the
way we emitted the global PDB string table. As evidence of this, you can
take any lld-generated PDB, run cvdump -stringtable on it, and it would
return no results.
My hypothesis was that cvdump could not *find* the string table to begin
with. Normally it would do this by looking in the "named stream map",
finding the string /names, and using its value as the stream index. If
this lookup fails, then cvdump would fail to load the string table.
To test this hypothesis, I looked at the name stream map generated by a
link.exe PDB, and I emitted exactly those bytes into an LLD-generated
PDB. Suddenly, cvdump could read our string table!
This code has always been hacky and we knew there was something we
didn't understand. After all, there were some comments to the effect of
"we have to emit strings in a specific order, otherwise things don't
work". The key to fixing this was finally understanding this.
The way it works is that it makes use of a generic serializable hash map
that maps integers to other integers. In this case, the "key" is the
offset into a buffer, and the value is the stream number. If you index
into the buffer at the offset specified by a given key, you find the
name. The underlying cause of all these problems is that we were using
the identity function for the hash. i.e. if a string's offset in the
buffer was 12, the hash value was 12. Instead, we need to hash the
string *at that offset*. There is an additional catch, in that we have
to compute the hash as a uint32 and then truncate it to uint16.
Making this work is a little bit annoying, because we use the same hash
table in other places as well, and normally just using the identity
function for the hash function is actually what's desired. I'm not
totally happy with the template goo I came up with, but it works in any
case.
The reason we never found this bug through our own testing is because we
were building a /parallel/ hash table (in the form of an
llvm::StringMap<>) and doing all of our lookups and "real" hash table
work against that. I deleted all of that code and now everything goes
through the real hash table. Then, to test it, I added a unit test which
adds 7 strings and queries the associated values. I test every possible
insertion order permutation of these 7 strings, to verify that it really
does work as expected.
Differential Revision: https://reviews.llvm.org/D43326
llvm-svn: 325386
Summary:
- Makes code more in line with LLVM style (e.g. const char * -> StringRef)
- Do not use formatv since we can construct message just by `+`
- Replace some odd types such as `const StringRef` with more common type
- Do not use default arguments if they are not necessary
Reviewers: sbc100
Subscribers: jfb, aheejin, llvm-commits, sunfish
Differential Revision: https://reviews.llvm.org/D43403
llvm-svn: 325383
This makes it possible to include clang-include-fixer as distribution
component when building Clang based toolchain using CMake.
Differential Revision: https://reviews.llvm.org/D43371
llvm-svn: 325381
There seems to be no reason to collect this list of symbols.
Also fix a bug where --exclude-libs would apply to all symbols that
appear in an archive's symbol table, even if the relevant archive
member was not added to the link.
Differential Revision: https://reviews.llvm.org/D43369
llvm-svn: 325380
Newer versions of the gnu assembler produce a X86_64_PLT32 for
calls. There is a change under review in llvm to do the same, so update
the tests to not depend on it.
We can still produce a R_X86_64_PC32 with ".long foo - .".
llvm-svn: 325379
The data type is assumed to be a vector, but sometimes it is not, leading
to an assertion.
Add simple test-case to verify this.
Differential revision: https://reviews.llvm.org/D42599
llvm-svn: 325378
This bug effected undefined symbols that were resolved by
existing defined symbols. We were skipping the signature
check in this case.
Differential Revision: https://reviews.llvm.org/D43399
llvm-svn: 325376
This handles them exactly the same way that we handle const integral
static data members with inline definitions, which is what MSVC does.
As a follow-up, now that we have a way to mark variables inline in the
AST, we should consider marking them implicitly inline there instead of
only treating them as inline in CodeGen. Unfortunately, this breaks a
lot of dllimport test cases, so that is future work for now.
Fixes PR36125.
llvm-svn: 325375
Summary:
This patch extends the promotion of alloca to vector to the arrays of up to 16 elements. Also we introduce
an option, -disable-promote-alloca-to-vector, to switch promotion to vector off, if needed.
Reviewers:
arsenm
Differential Revision:
https://reviews.llvm.org/D33559
llvm-svn: 325372
This seems to interfere with a target independent brcond combine that looks for the (srl (and X, C1), C2) pattern to enable TEST instructions. Once we flip, that combine doesn't fire and we end up exposing it to the X86 specific BT combine which causes us to emit a BT instruction. BT has lower throughput than TEST.
We could try to make the brcond combine aware of the alternate pattern, but since the flip was just a code size reduction and not likely to enable other combines, it seemed easier to just delay it until after lowering.
Differential Revision: https://reviews.llvm.org/D43201
llvm-svn: 325371
Add an explicit check before looking up symbol in SymbolIndices.
This was previously silently succeeding and returning zero for such
unnamed temporaries.
Differential Revision: https://reviews.llvm.org/D43365
llvm-svn: 325367
There were a few issues previously with the target
attribute diagnostics implementation that lead to the
attribute being added to the AST despite having an error
in it.
This patch changes that, and adds a test to ensure it
does not get added to the AST.
Differential Revision: https://reviews.llvm.org/D43359
llvm-svn: 325364
Now that we have R_ADDEND, UseSymVA was redundant. We only want to
write the symbol virtual address when using an expression other than
R_ADDEND.
llvm-svn: 325360
Summary:
The LazyValueInfo pass caches a copy of the DominatorTree when available.
Whenever there are pending DominatorTree updates within JumpThreading's
DeferredDominance object we cannot use the cached DT for LVI analysis.
This commit adds the new methods enableDT() and disableDT() to LVI.
JumpThreading also sets the appropriate usage model before calling LVI
analysis methods.
Fixes https://bugs.llvm.org/show_bug.cgi?id=36133
Reviewers: sebpop, dberlin, kuhar
Reviewed by: sebpop, kuhar
Subscribers: uabelho, llvm-commits, aprantl, hiraditya, a.elovikov
Differential Revision: https://reviews.llvm.org/D42717
llvm-svn: 325356
Summary:
In the current implementation of GPR Indexing Mode when the index is of non-uniform, the s_set_gpr_idx_off instruction
is incorrectly inserted after the loop. This will lead the instructions with vgpr operands (v_readfirstlane for example) to read incorrect
vgpr.
In this patch, we fix the issue by inserting s_set_gpr_idx_on/off immediately around the interested instruction.
Reviewers:
rampitec
Differential Revision:
https://reviews.llvm.org/D43297
llvm-svn: 325355
Based off the DemandedElts mask the and UNDEF elements returned from the SimplifyDemandedVectorElts calls to the shuffle operands, we can attempt to simplify the shuffle mask.
I had to be very conservative here as accepting post-legalized shuffle masks could cause problems for targets that legalize UNDEF mask elements back to inrange values (PowerPC), similarly combining to identity shuffle masks could cause too much UNDEF information to disappear for later combines.
llvm-svn: 325354
This adds Sema and Codegen tests for the vcvtr builtins
(because they were missing).
Differential Revision: https://reviews.llvm.org/D43372
llvm-svn: 325351
Running a bootstrap build with UBSan produces a number of instances where
we have signed integer overflow due to this transform. Change the type to
long to prevent this UB on 64-bit build machines.
llvm-svn: 325347
Summary:
o Collect suitable #include paths for index symbols. This also does smart mapping
for STL symbols and IWYU pragma (code borrowed from include-fixer).
o For global code completion, add a command for inserting new #include in each code
completion item.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, mgorny, ilya-biryukov, jkorous-apple, hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D42640
llvm-svn: 325343
Summary:
Fix a test failure on ARM hosts that was caused by a difference in the type of
size_t, by using a target-agnostic definiton.
Test Plan:
```
clang -cc1 -internal-isystem build/lib/clang/7.0.0/include -nostdsysteminc \
-std=c++14 -fcoroutines-ts -verify clang/test/SemaCXX/coroutines.cpp \
-fcxx-exceptions -fexceptions \
-triple armeb-none-eabi
```
llvm-svn: 325342
These instructions conflict with their full length variants
for the purposes of FastISel as they cannot be distingushed
based on the number and type of operands and predicates.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D41285
llvm-svn: 325341
The test was generating long unix socket names, and the addition of a
new folder in the previous patch pushed it over the limit (although
linux has a fairly generous limit for path names, this does not apply to
unix sockets).
Modify the test to use a shorter name instead.
llvm-svn: 325340
The reason this test was disabled is no longer relevant. However, it
didn't turn into an unexpected success because of a syntax error in the
test itself. This commit fixes that and re-enables the test.
llvm-svn: 325339
Summary:
The assertion will point directly to misbehaving code, so that
debugging related problems (like the one fixed by r325029) is easier.
Reviewers: hokein, ioeric, sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43246
llvm-svn: 325337
Zachary Turner