This is a shorthand for `Config->IsLE ? support::little : support::big`.

llvm-svn: 298445

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

No functionality change intended.

llvm-svn: 298443

No functionality change intended.

llvm-svn: 298442

llvm-svn: 298441

This is causing crashes in clang, so reverting until the problem
is figured out.

llvm-svn: 298440

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

llvm-svn: 298438

llvm-svn: 298437

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

llvm-svn: 298435

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

llvm-svn: 298433

llvm-svn: 298432

D28494 adds another parameter to @llvm.objectsize. Clang needs to be
sure to pass that third arg whenever applicable.

llvm-svn: 298431

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

llvm-svn: 298427

[X86][MS-compatability][clang] allow MS TYPE/SIZE/LENGTH operators as a part of a compound expression

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

[X86][MS-compatability][llvm] allow MS TYPE/SIZE/LENGTH operators as a part of a compound expression

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

llvm-svn: 298423

llvm-svn: 298422

Prevent cppcoreguidelines-pro-bounds-array-to-pointer-decay from diagnosing array to pointer decay stemming from system macros.

Patch by Breno Rodrigues Guimaraes.

llvm-svn: 298421

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

llvm-svn: 298419

llvm-svn: 298418

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

Implement P0548: 'common_type and duration' This involves a subtle change in the return type of the unary +/- operators for std::chrono::duration, though I expect that no one will notice.

llvm-svn: 298416

llvm-svn: 298415

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

llvm-svn: 298412

Disable compilation of libomptarget on MacOS X.

Differential Revision: https://reviews.llvm.org/D31055

llvm-svn: 298411

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