This issue was encountered on libcmt.pdb, which has a type record that
looks like this:
Struct (0x1094) {
TypeLeafKind: LF_STRUCTURE (0x1505)
MemberCount: 3
Properties [ (0x200)
HasUniqueName (0x200)
]
FieldList: <field list> (0x1093)
DerivedFrom: 0x0
VShape: 0x0
SizeOf: 4
Name: <unnamed-tag>
LinkageName: .?AU<unnamed-tag>@@
}
The checks for startswith/endswith "<unnamed-tag>" should look at the
display name, not the linkage name.
llvm-svn: 274376
We were asserting that our type records were valid when emitting
assembly, but not when emitting an object file.
I've been seeing lots of LNK1285 errors (corrupt PDB) during incremental
debug self-host builds with the MSVC linker, and hopefully this will
catch some of them earlier.
llvm-svn: 274373
Enable testing different scheduling variants if sgpr usage
is very high. It was previously disabled because of a bug
in handleMove, but it has been fixed since.
Patch by Axel Davy
llvm-svn: 274372
This change fixes an error in comparing the existing schedule on the team to
the new schedule, in the chunk field. Also added additional checks and used
KMP_CHECK_UPDATE where appropriate.
Patch by Terry Wilmarth.
Differential Revision: http://reviews.llvm.org/D21897
llvm-svn: 274371
This is important for building libclc. Since r273039 tests are failing
due to now emitting calls to these functions instead of emitting the
DAG node. The libm function names are implemented for OpenCL, and should
call the locally defined versions, so -fno-builtin is used. The IR
Some functions use the __builtins and expect the intrinsics to be
emitted. Without this we end up with nobuiltin calls to intrinsics
or to unsupported library calls.
llvm-svn: 274370
EPCC Performance of single is considerably worse than plain barrier.
Adding a read-only check to the code before the atomic compare-and-store
helps considerably.
Patch by Terry Wilmarth.
Differential Revision: http://reviews.llvm.org/D21893
llvm-svn: 274369
Summary: original test may have different bahavior on different bot, specifically it broke llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21931
llvm-svn: 274368
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
This involved running 2to3 on it and adjusting all uses of subprocess to use
universal_newlines=True so the output is text instead of binary. It remains
compatible with Python 2.7.
llvm-svn: 274365
Summary:
As this test will create a new target, it will cause all following tests
to fail when running in platform mode, if the new target does not match
the existing architecture (for example, x86 vs x86_64).
Reviewers: zturner, spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21906
llvm-svn: 274364
Use MachineInstr& to avoid implicit conversions from
MachineBasicBlock::iterator to MachineInstr*. In one case, this could
use a range-based for loop, but the other loops iterated in reverse
order.
One of the reverse-loops checked the MachineInstr* for nullptr, a
condition that is provably unreachable. (And even if my proof has a
flaw, UBSan would catch the bug.)
llvm-svn: 274360
Summary: The code generation should be independent of the debug info.
Reviewers: zansari, davidxl, mkuper, majnemer
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D21911
llvm-svn: 274357
Use MachineInstr& instead of MachineInstr* in RegAllocFast to avoid
implicit conversions from MachineInstrBundleIterator. RAFast::spillAll
and RAFast::spillVirtReg still take iterators, since their argument may
be an end iterator from MachineBasicBlock::getFirstTerminator.
llvm-svn: 274353
Previously out-of-tree passes could detect if LLVM was built with
LLVM_BUILD_32_BITS by looking for -m32 in LLVM_DEFINITIONS, but as of r271871
it no longer appears there. Resolve this by instead emitting LLVM_BUILD_32_BITS
in LLVMConfig so it can be checked for directly.
Differential Revision: http://reviews.llvm.org/D21434
llvm-svn: 274351
This feature needs to be explicitly enabled by overriding shouldTraversePostOrder()
as it has performance drawbacks for the iterative Stmt-traversal.
Patch by Raphael Isemann!
Reviewed by Richard Smith and Benjamin Kramer.
llvm-svn: 274348
No functional changes. Just created wrapper classes around the 3
and 4 reg mult and mac instruction classes.
Differential Revision: http://reviews.llvm.org/D21549
llvm-svn: 274347
This is PR28358
According to
https://www.akkadia.org/drepper/dsohowto.pdf
"The fourth point, the VERS 1.0 version being referred to in the VERS 2.0 definition, is not really important in symbol versioning. It marks the predecessor relationship of the two versions and it is done to maintain the similar- ities with Solaris’ internal versioning. It does not cause any problem it might in fact be useful to a human reader so predecessors should always be mentioned."
Patch partially reverts 273423 "[ELF] - Implemented version script hierarchies.",
version references are just ignored now.
Differential revision: http://reviews.llvm.org/D21888
llvm-svn: 274345
This was reverted in r268740 because of problems with corresponding Clang change.
Clang change was updated and resubmitted in r274220.
Check calling convention in AMDGPUMachineFunction::isKernel
This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF.
Also, in the future unused non-kernels may be optimized.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19917
llvm-svn: 274341
Summary: dst_sel and dst_unused disabled for VOPC as they have no effect on result
Reviewers: artem.tamazov, tstellarAMD, vpykhtin
Subscribers: arsenm, kzhuravl
Differential Revision: http://reviews.llvm.org/D21376
llvm-svn: 274340
For the most part this simplifies all callers. There were two places in X86 that needed an explicit makeArrayRef to shorten a statically sized array.
llvm-svn: 274337
Group" sections while lowering. In particular, for ELF sections this is
useful for creating function-specific groups that get merged into the
same named section.
Also use const Twine& instead of StringRef for the getELF functions
while we're here.
Differential Revision: http://reviews.llvm.org/D21743
llvm-svn: 274336
This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.
Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).
One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.
llvm-svn: 274331
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
Reid Kleckner