llvm-svn: 281600

It was only really there as a sentinel when instructions had to have precisely
one type. Now that registers are typed, each register really has to have a type
that is sized.

llvm-svn: 281599

llvm-svn: 281598

Otherwise everything that needs to work out what size they are has to keep a
DataLayout handy, which is a bit silly and very annoying.

llvm-svn: 281597

The ARM-specific C attributes (currently just interrupt) need to check
for both the big- and little-endian versions of the triples, so that
they are accepted for both big and little endian targets.

TargetWindows and TargetMicrosoftCXXABI also only use the little-endian
triples, but this is correct as windows is not supported on big-endian
ARM targets (and this is asserted in lib/Basic/Targets.cpp).

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

llvm-svn: 281596

It is a new attribute emitted by clang as a GNU extension and will
be part of Dwarf5. The purpose of the attribute is to specify a compile
unit level base value for all DW_AT_ranges to reduce the number of
relocations have to be done by the linker.

Fixes (at least partially): https://llvm.org/pr28826

Differential revision: https://reviews.llvm.org/D24514

llvm-svn: 281595

llvm-svn: 281594

Summary: Continue work on PR30351

Reviewers: vitalybuka, kcc, eugenis

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 281593

Summary: Continue work on PR30351

Reviewers: vitalybuka, kcc, eugenis

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 281592

Summary: Continue work on PR30351

Reviewers: vitalybuka, kcc, eugenis

Subscribers: llvm-commits, kubabrecka

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

llvm-svn: 281591

llvm-svn: 281590

Copying in the full text of the function doesn't help at all when we
already know that it's never executed. Just say that it's unexecuted --
the relevant source text has already been printed.

llvm-svn: 281589

Doing so is pointless, since the whole view is usually visible in a
small amount of space.

llvm-svn: 281588

The change in rL281586 is in llvm component and tests updated here are
in clang component, so I have to commit them consecutively.

llvm-svn: 281587

The patch is to partially fix PR10584. Correlated Value Propagation queries LVI
to check non-null for pointer params of each callsite. If we know the def of
param is an alloca instruction, we know it is non-null and can return early from
LVI. Similarly, CVP queries LVI to check whether pointer for each mem access is
constant. If the def of the pointer is an alloca instruction, we know it is not
a constant pointer. These shortcuts can reduce the cost of CVP significantly.

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

llvm-svn: 281586

Copy variable LLVM_BUILD_MAIN_SRC_DIR from LLVMConfig.cmake to
LLVM_MAIN_SRC_DIR as it is named for in-tree builds. This ensures that
add_lit_target() can reliably find llvm-lit which is not necessarily
in the PATH.

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

llvm-svn: 281585

llvm-svn: 281584

llvm-svn: 281583

llvm-svn: 281582

llvm-svn: 281581

llvm-svn: 281580

Having the same title, timestamp, etc. occur repeatedly creates an
unnecessary distraction when paging through a report.

llvm-svn: 281579

E.g the 'showProjectSummary' test contains some checks which can't fail
because they match themselves...

llvm-svn: 281578

[libFuzzer] implement print_pcs with trace-pc-guard. Change the trace-pc-guard heuristic for 8-bit counters to look more like in AFL (not that it's provable better, but the existin test preferes this heuristic)

llvm-svn: 281577

Avoid redefining the weak stub when building gotsan.cc

llvm-svn: 281576

The test exercises the branch in scev expansion when the value in ValueOffsetPair
is a ptr and the offset is not divisible by the elem type size of value.

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

llvm-svn: 281575

llvm-svn: 281574

[doc] [CUDA] Add sections about STL support and differences between nvcc and clang to CompileCudaWithLLVM.rst.

llvm-svn: 281573

llvm-svn: 281570

This keeps them from conflicting with other symbols names, so it's
worth their being less convenient to use for indexing.

llvm-svn: 281569

llvm-svn: 281568

'weak' doesn't behave like it does on linux.

llvm-svn: 281567

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281566

Just use lgamma_r and ignore the value returned in the second argument

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281565

Ported from the amd-builtins branch, which is itself based on the
Sun Microsystems implementation.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281564

This macro is currently unused, but I plan to use it shortly.

The previous form did casts of pointers without an address space, which
doesn't work so well for CL 1.x.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281563

This patch causes a couple of issues:

1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.

2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.

This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.

llvm-svn: 281562

The pattern matching and transforms are identical; the cmp predicate just changes.

llvm-svn: 281561

llvm-svn: 281560

llvm-svn: 281559