We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.

Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.

So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.

llvm-svn: 315525

llvm-svn: 315524

  - Move PAL metadata definitions to AMDGPUMetadata
  - Make naming consistent with HSA metadata

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

llvm-svn: 315523

  - Rename AMDGPUCodeObjectMetadata to AMDGPUMetadata (PAL metadata will be included in this file in the follow up change)
  - Rename AMDGPUCodeObjectMetadataStreamer to AMDGPUHSAMetadataStreamer
  - Introduce HSAMD namespace
  - Other minor name changes in function and test names

llvm-svn: 315522

In r315079, fs::rename was reimplemented in terms of CreateFile and
SetFileInformationByHandle. Unfortunately, the latter isn't supported by
Wine. This adds a fallback to MoveFileEx for that case.

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

llvm-svn: 315520

llvm-svn: 315519

Apple's API verification tool (tapi) checks that the symbols exported
from a program match a whitelist. When the program uses the profile
runtime, some additional symbols which are typically not part of the
regular whitelist must be exported.

If we're using symbol export directives along with the profile runtime
on Darwin, the driver needs to export the additional symbols to avoid
verification failures.

rdar://problem/30067753

llvm-svn: 315518

The compiler-rt implementation already supported it, it just wasn't exposed.

llvm-svn: 315517

[Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 315516

llvm-svn: 315515

llvm-svn: 315514

Summary:
This adds a set of new directives that describe 32-bit x86 prologues.
The directives are limited and do not expose the full complexity of
codeview FPO data. They are merely a convenience for the compiler to
generate more readable assembly so we don't need to generate tons of
labels in CodeGen. If our prologue emission changes in the future, we
can change the set of available directives to suit our needs. These are
modelled after the .seh_ directives, which use a different format that
interacts with exception handling.

The directives are:
  .cv_fpo_proc _foo
  .cv_fpo_pushreg ebp/ebx/etc
  .cv_fpo_setframe ebp/esi/etc
  .cv_fpo_stackalloc 200
  .cv_fpo_endprologue
  .cv_fpo_endproc
  .cv_fpo_data _foo

I tried to follow the implementation of ARM EHABI CFI directives by
sinking most directives out of MCStreamer and into X86TargetStreamer.
This helps avoid polluting non-X86 code with WinCOFF specific logic.

I used cdb to confirm that this can show locals in parent CSRs in a few
cases, most importantly the one where we use ESI as a frame pointer,
i.e. the one in http://crbug.com/756153#c28

Once we have cdb integration in debuginfo-tests, we can add integration
tests there.

Reviewers: majnemer, hans

Subscribers: aemerson, mgorny, kristof.beyls, llvm-commits, hiraditya

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

llvm-svn: 315513

They never passed. This change excludes them from 'check-all'.

llvm-svn: 315512

They never actually worked, but this way they are not included in "check-all".

llvm-svn: 315511

llvm-svn: 315510

Summary:
This is a new attempt at D38706, which had 2 issues.

The first one was that it broke TSan, because `sanitizer_errno.h` was not
directly included in `tsan_mman.cc`. This fixes the include.

The second one was that it broke the nolibc build, because `__errno_location`
couldn't be found. This adds the new .cc to the libcdep list instead of the
base one.

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: kubamracek, mgorny, llvm-commits

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

llvm-svn: 315509

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

llvm-svn: 315508

llvm-svn: 315507

llvm-svn: 315506

llvm-svn: 315505

Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.

Reviewers: vlad.tsyrklevich

Reviewed By: vlad.tsyrklevich

Subscribers: mgorny, llvm-commits, pcc, kcc

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

llvm-svn: 315504

llvm-svn: 315503

Summary:
Fixes a bogus iterator resulting from the removal of a block's first instruction at the point that incremental update is enabled.

Patch by Paul Walker.

Reviewers: fhahn, Gerolf, efriedma, MatzeB

Reviewed By: fhahn

Subscribers: aemerson, javed.absar, llvm-commits

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

llvm-svn: 315502

llvm-svn: 315501

[PowerPC] Utilize DQ-Form instructions for spill/restore and fix FrameIndex elimination to only use `lis/addi` if necessary.

Currently we produce a bunch of unnecessary code when emitting the
prologue/epilogue for spills/restores.  Namely, if the load from stack
slot/store to stack slot instruction is an X-Form instruction, we will
always produce an LIS/ORI sequence for the stack offset.

Furthermore, we have not exploited the P9 vector D-Form loads/stores for this
purpose.

This patch address both issues.

Specifying the D-Form load as the instruction to use for stack spills/reloads
should be safe because:

1. The stack should be aligned according to the ABI
2. If the stack isn't aligned, PPCRegisterInfo::eliminateFrameIndex() will
   check for the offset being a multiple of 16 and will convert it to an
   X-Form instruction if it isn't.

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

llvm-svn: 315500

Previously we would only look in the current directory for a
resource, which might not be the same as the directory of the
rc file.  Furthermore, MSVC rc supports a /I option, and can
also look in the system environment.  This patch adds support
for this search algorithm.

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

llvm-svn: 315499

In practice, with code built with clang, there are still unresolved
issues with DW_CFA_GNU_args_size though.

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

llvm-svn: 315498

llvm-svn: 315497

Add case to handle new event lldb::eBreakpointEventTypeAutoContinueChanged.

llvm-svn: 315496

This patch doesn't change the behavior of the program because it
would eventually return None at end of the function. But it is
better to return None early if we know it will eventually happen.

llvm-svn: 315495

This reverts commit r315493 which is failing to build on sanitizer-windows.

llvm-svn: 315494

In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.

Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.

The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)

Finally, a last changeset will update the Fuchsia implementation.

Patch by Julia Hansbrough

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

llvm-svn: 315493

llvm-svn: 315492

[SCEV] Properly handle the case of a non-constant start with a zero accum in ScalarEvolution::createAddRecFromPHIWithCastsImpl

Summary:
 This patch fixes an error in the patch to ScalarEvolution::createAddRecFromPHIWithCastsImpl
made in D37265. In that patch we handle the cases where the either the start or accum values can be
zero after truncation. But, we assume that the start value must be a constant if the accum is
zero. This is clearly an erroneous assumption. This change removes that assumption.

Reviewers: sanjoy, dorit, mkazantsev

Reviewed By: sanjoy

Subscribers: llvm-commits

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

llvm-svn: 315491

llvm-svn: 315490

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

llvm-svn: 315489

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

llvm-svn: 315488

Fixes PR34872.

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

llvm-svn: 315487

Summary:
Makes clang-[proto-]fuzzer compatible with flags specified by OSS-Fuzz.

https://llvm.org/pr34314

Reviewers: vitalybuka, kcc

Reviewed By: kcc

Subscribers: cfe-commits, mgorny

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

llvm-svn: 315486

Legalization of fp128 assumes things that we should have asserts for,
so that's another potential improvement.

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

llvm-svn: 315485