Use EmitLabelOffsetDifference for handling on darwin platform when
non-darwin platforms use EmitLabelPlusOffset.

Also fix a bug in EmitLabelOffsetDifference where the size is hard-coded
to 4 even though Size is passed in as an argument.

llvm-svn: 193660

To support ref_addr, we calculate the section offset of a DIE (i.e. offset
of a DIE from beginning of the debug info section). The Offset field in DIE
is currently CU-relative. To calculate the section offset, we add a
DebugInfoOffset field in CompileUnit to store the offset of a CU from beginning
of the debug info section. We set the value in DwarfUnits::computeSizeAndOffset
for each CompileUnit.

A helper function DIE::getCompileUnit is added to return the CU DIE that
the input DIE belongs to. We also add a map CUDieMap in DwarfDebug to help
finding the CU for a given CU DIE.

For a cross-referenced DIE, we first find the CU DIE it belongs to with
getCompileUnit, then we use CUDieMap to get the corresponding CU for the CU DIE.
Adding the section offset of the CU with the CU-relative offset of a DIE gives
us the seciton offset of the DIE.

We correctly emit ref_addr with relocation using EmitLabelPlusOffset when
doesDwarfUseRelocationsAcrossSections is true.

This commit handles the emission of DW_FORM_ref_addr when we have an attribute
with FORM_ref_addr. A follow-on patch will start using ref_addr when adding a
DIEEntry. This commit will be tested and verified in the follow-on patch.

Reviewed off-list by Eric, Thanks.

llvm-svn: 193658

after the DIE creation, we construct the context first.

Ensure that we create the context before we create a type so that we can add
the newly created type to the parent. Remove last use of addToContextOwner
now that it's not needed.

We use createAndAddDIE to wrap around "new DIE(". Now all shareable DIEs
should be added to their parents right after the creation.

Reviewed off-list by Eric, Thanks.

llvm-svn: 193657

Helper functions are added:
emitPostLd: emit a post-increment load operation with given size.
emitPostSt: emit a post-increment store operation with given size.

No functionality change.

llvm-svn: 193656

This modifies the pass to classify every SSP-triggering AllocaInst according to
an SSPLayoutKind (LargeArray, SmallArray, AddrOf).  This analysis is collected
by the pass and made available for use, but no other pass uses it yet.

The next patch will make use of this analysis in PEI and StackSlot
passes.  The end goal is to support ssp-strong stack layout rules.

WIP.

Differential Revision: http://llvm-reviews.chandlerc.com/D1789

llvm-svn: 193653

llvm-svn: 193651

Use 32-bit types for the array instead of 64. This should
generally be better anyway.

In optimized + assert builds, I saw a failure when a
cond code / type combination that is never set was loading
a non-zero value and hitting the != Promote assert.

It turns out when loading the 64-bit value to do the shift,
the assembly loads the 2 32-bit halves from non-consecutive
addresses. The address the second half of the loaded uint64_t
doesn't include the offset of the array in the struct. Instead
of being offset + 4, it's just + 4.

I'm not entirely sure why this wasn't observed before.
setCondCodeAction isn't heavily used by the in-tree targets,
and not with the higher valued vector SimpleValueTypes. Only
PPC is using one of the > 32 valued types, and that is probably
never used by anyone on a 32-bit MSVC compiled host.

I ran into this when upgrading LLVM versions, so I guess the
value loaded from the nonsense address happened to work out
before.

No test since I'm not really sure if / how it can be reproduced
with the current in tree targets, and it's not supposed to change
anything.

llvm-svn: 193650

Removing a switch statement that contains only a default label.  This resolves an MSVC warning.  No functional change intended.

llvm-svn: 193649

llvm-svn: 193641

llvm-svn: 193637

llvm-svn: 193632

This allows constructing a Mangler with just a TargetMachine.

llvm-svn: 193630

Add a tag before the name attribute for readability. Use CHECK-NEXT
instead of CHECK-NOT followed by a CHECK. Add new lines to separate checking
of different DIEs.

llvm-svn: 193629

llvm-svn: 193627

llvm-svn: 193626

Fixes PR17690

llvm-svn: 193625

llvm-svn: 193624

llvm-svn: 193623

v2:
  - Fix LDS size calculation

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 193621

llvm-svn: 193620

Based on D2050 by Timur Iskhodzhanov.

llvm-svn: 193619

llvm-svn: 193618

llvm-svn: 193617

llvm-svn: 193616

They are used in some packages. For example:
http://packages.ubuntu.com/saucy/i386/llvm-3.4/filelist

This fixes pr17721.

llvm-svn: 193612

Add some missing tests, factor out a test not specific to v8 into
its own file.

llvm-svn: 193611

llvm-svn: 193609

MSVC can't comprehend
  template<typename T, size_t N>
  ArrayRef<T> makeArrayRef(const T (&Arr)[N]) {
    return ArrayRef<T>(Arr);
  }
if Arr is
  static const uint8_t sizes[];
declared in a templated and defined a few lines later.

I'll send a proper fix (i.e. get rid of unnecessary templates) for review soon.

llvm-svn: 193604

Adds a subtarget feature for the CRC instructions (optional in v8-A) to the ARM (32-bit) backend.

Differential Revision: http://llvm-reviews.chandlerc.com/D2036

llvm-svn: 193599

Sorry Peter Zotov, entirely my fault.

llvm-svn: 193598

Patch by Peter Zotov

Differential Revision: http://llvm-reviews.chandlerc.com/D1910

llvm-svn: 193597

This is used in the Linux kernel, and effectively just means "print an
address".

llvm-svn: 193593

after the DIE creation, we construct the context first.

This touches creation of namespaces and global variables. The purpose is to
handle all DIE creations similarly: constructs the context first, then creates
the DIE and immediately adds the DIE to its parent.

We use createAndAddDIE to wrap around "new DIE(".

llvm-svn: 193589

llvm-svn: 193580

llvm-svn: 193579

llvm-svn: 193576

  error: conversion from `const uint8_t*' to non-scalar type `llvm::ArrayRef<unsigned char>' requested

llvm-svn: 193575

Updated a test case that assumed that <2 x double> would vectorize to use
<4 x float>.

radar://15338229

llvm-svn: 193574

By vectorizing a series of srl, or, ... instructions we have obfuscated the
intention so much that the backend does not know how to fold this code away.

radar://15336950

llvm-svn: 193573

No test case, because with the current cost model we don't see a difference.
An upcoming ARM memory cost model change will expose and test this bug.

radar://15332579

llvm-svn: 193572