Currently the default C calling convention functions are treated
the same as compute kernels. Make this explicit so the default
calling convention can be changed to a non-kernel.
Converted with perl -pi -e 's/define void/define amdgpu_kernel void/'
on the relevant test directories (and undoing in one place that actually
wanted a non-kernel).
llvm-svn: 298444
A bool is represented by a single byte, which the ARM ABI requires to be either
0 or 1. So we cannot use G_ANYEXT when legalizing the type.
llvm-svn: 298439
StringMap's iterators did not support LLVM's
iterator_facade_base, which made it unusable in various
STL algorithms or with some of our range adapters.
This patch makes both StringMapConstIterator as well as
StringMapIterator support iterator_facade_base.
With this in place, it is easy to make an iterator adapter
that iterates over only keys, and whose value_type is
StringRef. So I add StringMapKeyIterator as well, and
provide the method StringMap::keys() that returns a
range that can be iterated.
Differential Revision: https://reviews.llvm.org/D31171
llvm-svn: 298436
ADL as reasonable extension points.
All of this would be cleaner if this code followed the more usual LLVM
convention of not having deeply nested namespaces inside of .cpp files
and instead having a `using namespace ...;` at the top. Then the static
function would be in the global namespace and easily referred to as
`::join`. Instead we have to write a fairly contrived qualified name.
I figure the authors can clean this up with a less ambiguous name, using
the newly provided LLVM `join` function, or any other solution, but this
at least fixes the build.
llvm-svn: 298434
This adds a parameter to @llvm.objectsize that makes it return
conservative values if it's given null.
This fixes PR23277.
Differential Revision: https://reviews.llvm.org/D28494
llvm-svn: 298430
Summary:
Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in pro
file, thus we do not want to inline hot callsites in the first phase.
Reviewers: tejohnson, eraman
Reviewed By: tejohnson
Subscribers: mehdi_amini, cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31202
llvm-svn: 298429
Summary: Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in profile, thus we do not want to inline hot callsites in the first phase.
Reviewers: tejohnson, eraman
Reviewed By: tejohnson
Subscribers: mehdi_amini, llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31201
llvm-svn: 298428
This patch introduces X86AsmParser with the ability to handle the aforementioned ops within compound "MS" arithmetical expressions.
Currently - only supported as a stand alone Operand, e.g.:
"TYPE X"
now allowed :
"4 + TYPE X * 128"
LLVM side: https://reviews.llvm.org/D31173
Differential Revision: https://reviews.llvm.org/D31174
llvm-svn: 298426
This patch introduces X86AsmParser with the ability to handle the aforementioned ops within compound "MS" arithmetical expressions.
Currently - only supported as a stand alone Operand, e.g.:
"TYPE X"
now allowed :
"4 + TYPE X * 128"
Clang side: https://reviews.llvm.org/D31174
Differential Revision: https://reviews.llvm.org/D31173
llvm-svn: 298425
Summary:
This change should fixes the export of CLANG_INCLUDE_DIRS variable in ClangConfig.cmake.
Unlike for the other variables, CLANG_INSTALL_PREFIX wasn't escaped meaning CLANG_INCLUDE_DIRS
resulting in the path "/include" instead of "${CLANG_INSTALL_PREFIX}/include".
Reviewers: beanz
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D30911
llvm-svn: 298424
For variables in generic address spaces, for example:
```
unsigned char V[6442450944];
...
```
the address space is not yet known when we get into
*getConstantArrayType*, it is 0. AMDGCN target's
address space 0 has 32 bits pointers, so when we
call *getPointerWidth* with 0, the array size is
trimmed to 32 bits, which is not right.
Differential Revision: https://reviews.llvm.org/D30845
llvm-svn: 298420
including the amended (no UB anymore) fix for adding/subtracting -2147483648.
This reverts r298328 "[ARM] Revert r297443 and r297820."
and partially reverts r297842 "Revert "[Thumb1] Fix the bug when adding/subtracting -2147483648""
llvm-svn: 298417
This is a fixup for the unit tests from r298278 (originally r298165).
Since the buffer that RawB2 pointed at was later deleted, a new call to
getBuffer may very well return a buffer at the same/old address. Which is
fine. Just delete the spurious check.
A Windows bot was occasionally hitting this in practice:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7086
llvm-svn: 298414
Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed.
Reviewers: davidxl, beanz
Reviewed By: beanz
Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D31098
llvm-svn: 298413
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
llvm-svn: 298410
Summary:
NetBSD is a modern ELF UNIX-like system.
There is requires DynamicLoaderPOSIXDYLD e.g. for ELF AUXV reading from the client.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, kettenis
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31192
llvm-svn: 298409
Summary:
This is the base for introduction of further features to support Process Tracing on NetBSD, in local and remote setup.
This code is also a starting point to synchronize the development with other BSDs. Currently NetBSD is ahead and other systems can catch up.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Reviewed By: labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31138
llvm-svn: 298408
Summary:
NetBSD is an ELF platform and it uses Elf Auxiliary Vector like Linux and other modern BSDs.
While there enable QPassSignals for the NetBSD port as well.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, kettenis, joerg, emaste
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31146
llvm-svn: 298407
Summary:
NetBSD can share the same logging functionality with Linux and FreeBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, emaste, joerg, kettenis
Reviewed By: labath, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31191
llvm-svn: 298406
Summary:
NetBSD native threads are printed as 64-bit unsigned integers.
The underlying system type of a thread identity is lwpid_t of type int32_t. For consistency with Linux and FreeBSD share the 64-bit unsigned integer type.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, kettenis, joerg, emaste
Reviewed By: labath, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31132
llvm-svn: 298405
Summary: ModuleSummary should use the standard interface of ProfileSummary::getProfileCount.
Reviewers: eraman, tejohnson
Reviewed By: tejohnson
Subscribers: tejohnson, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D31154
llvm-svn: 298404
[Hexagon] Recognize polynomial-modulo loop idiom again
Regain the ability to recognize loops calculating polynomial modulo
operation. This ability has been lost due to some changes in the
preceding optimizations. Add code to preprocess the IR to a form
that the pattern matching code can recognize.
llvm-svn: 298400
Rui Ueyama