These are 2 new value currently in experimental status used when split
debug info is enabled.
Differential revision: http://reviews.llvm.org/D12238
llvm-svn: 245931
The array is indexed by the value in the DW_FORM filed what can be
bigger then the size of the array. This CL add bound checking to avoid
buffer overflows
Differential revision: http://reviews.llvm.org/D12239
llvm-svn: 245930
Setting and getting register values as bytes instead of depending on the 128 bit integer support in register value.
This patch will fix the build failure in the release branch.
Reviewers: tberghammer, clayborg, hans
Subscribers: bhushan, nitesh.jain, jaydeep, lldb-commits
Differential: http://reviews.llvm.org/D12275
llvm-svn: 245927
Summary: Update python script, so that it doesn't print that line in new tests.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D12281
llvm-svn: 245926
This fixes two issues in x86 fptoui lowering.
1) Makes conversions from f80 go through the right path on AVX-512.
2) Implements an inline sequence for fptoui i64 instead of a library
call. This improves performance by 6X on SSE3+ and 3X otherwise.
Incidentally, it also removes the use of ftol2 for fptoui, which was
wrong to begin with, as ftol2 converts to a signed i64, producing
wrong results for values >= 2^63.
Patch by: mitch.l.bodart@intel.com
Differential Revision: http://reviews.llvm.org/D11316
llvm-svn: 245924
_rotl, _rotwl and _lrotl (and their right-shift counterparts) are official x86
intrinsics, and should be supported regardless of environment. This is in contrast
to _rotl8, _rotl16, and _rotl64 which are MS-specific.
Note that the MS documentation for _lrotl is different from the Intel
documentation. Intel explicitly documents it as a 64-bit rotate, while for MS,
since sizeof(unsigned long) for MSVC is always 4, a 32-bit rotate is implied.
Differential Revision: http://reviews.llvm.org/D12271
llvm-svn: 245923
It doesn't solve the problem, when for example we load something, and
then assume that it is the same as some constant value, because
globalopt will fail on unknown load instruction. The proposed solution
would be to skip some instructions that we can't evaluate and they are
safe to skip (f.e. load, assume and many others) and see if they are
required to perform optimization (f.e. we don't care about ephemeral
instructions that may appear using @llvm.assume())
http://reviews.llvm.org/D12266
llvm-svn: 245919
This reverts commit 433bfd94e4b7e3cc3f8b08f8513ce47817941b0c.
Broke some bot, have to see why it passed locally.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 245917
We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.
It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.
Reviewers: ributzka
Differential Revision: http://reviews.llvm.org/D12263
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 245916
- Fix some grammatical and typographical errors.
- Try to improve upon some awkward/nonstandard phrasings.
- Expand slightly the treatment of how you specify arguments to cmake.
- Update the list of possible LLVM_BUILD_TESTS and state where to find the
definitive list.
- Correct the name of llvm-tblgen.
- Expand slightly the treatment of several build options, including
LLVM_LIT_TOOLS_DIR, LLVM_ENABLE_FFI, and LLVM_EXTERNAL_project_SOURCE_DIR.
Patch by Brian R. Gaeke!
Differential Revision: http://reviews.llvm.org/D11862
llvm-svn: 245911
Summary:
This is more consistent with other targets and also makes the -fuse-ld
flag work.
Reviewers: jvoung
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10697
llvm-svn: 245908
We might end up with a trivial copy as the addend, and if so, we should ignore
the corresponding FMA instruction. The trivial copy can be coalesced away later,
so there's nothing to do here. We should not, however, assert. Fixes PR24544.
llvm-svn: 245907
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
Apparently std::vector::erase(const_iterator) (as opposed to the
non-const iterator) is a part of C++11 but it seems this is not available
on all the buildbots.
llvm-svn: 245900
This change moves LTOCodeGenerator's ownership of the merged module to a
field of type std::unique_ptr<Module>. This helps simplify parts of the code
and clears the way for the module to be consumed by LLVM CodeGen (see D12132
review comments).
Differential Revision: http://reviews.llvm.org/D12205
llvm-svn: 245891
Previously we had to call __sanitizer_cov_dump() from tool-specific
callbacks - instead, let sanitizer_common library handle this in a
single place.
This is a re-application of r245770, with slightly different approach
taken.
llvm-svn: 245890
This is required to properly re-apply r245770:
1) We should be able to dump coverage in __sanitizer::Die() if coverage
collection is turned on.
2) We don't want to explicitly do this in every single
sanitizer that supports it.
3) We don't want to link in coverage (and therefore symbolization) bits
into small sanitizers that don't support it (safestack).
The solution is to make InitializeCoverage() register its own Die()
callback that would call __sanitizer_cov_dump(). This callback should be
executed in addition to another tool-specific die callbacks (if there
are any).
llvm-svn: 245889
Summary: I forgot to squash git commits before doing an svn dcommit of D12219. Reverting, and re-submitting.
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D12298
llvm-svn: 245886
Tamas Berghammer