For pointer-typed function arguments, enhanced alignment can be asserted using
the 'align' attribute. When inlining, if this enhanced alignment information is
not otherwise available, preserve it using @llvm.assume-based alignment
assumptions.

llvm-svn: 219876

Clang CodeGen had a utility function for creating pointer alignment assumptions
using the @llvm.assume intrinsic. This functionality will also be needed by the
inliner (to preserve function-argument alignment attributes when inlining), so
this moves the utility function into IRBuilder where it can be used both by
Clang CodeGen and also other LLVM-level code.

llvm-svn: 219875

In AVX512f we support 64x2 and 32x8 inserts via matching them to 32x4 and 64x4
respectively.  These are matched by "Alt" Pat<>'s (Alt stands for alternative
VTs).

Since DQ has native support for these intructions, I peeled off the non-"Alt"
part of the baseclass into vinsert_for_size_no_alt. The DQ instructions are
derived from this multiclass.  The "Alt" Pat<>'s are disabled with DQ.

Fixes <rdar://problem/18426089>

llvm-svn: 219874

This is in preparation to adding DQ subvector inserts to this testcase.

llvm-svn: 219873

We're inserting into a 8 wide vector, so the index should be < 8.

llvm-svn: 219872

The new attributes are NumElts and the CD8TupleForm.  This prepares the code
to enable x8 and x2 inserts.

NFC, no change in X86.td.expanded except for the new attributes.

llvm-svn: 219871

It's the W bit that selects between 32 or 64 elt type and not the opcode.  The
opcode selects between the width of the insert (128 or 256).

llvm-svn: 219870

an uninitialized value.  In reality the code block that 
initializes it and the code block that restores it will always
match up - but the analyzer doesn't know that and I want to 
quiet it, so...
clang static analyzer fixit.

llvm-svn: 219869

Zero-width BFEs are combined away already, so there's no point in
handling them.

llvm-svn: 219868

llvm-svn: 219867

This CL introduces MachOObjectFile::getUuid(). This function returns an ArrayRef to the object file's UUID, or an empty ArrayRef if the object file doesn't contain an LC_UUID load command.
The new function is gonna be used by llvm-symbolizer.

llvm-svn: 219866

possibly use it uninitialized in a log message later.
clang static analyzer fixit.

llvm-svn: 219865

llvm-svn: 219864

llvm-svn: 219863

llvm-svn: 219862

llvm-svn: 219861

[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if

Doing s/append_if/append_list_if/, no functional change.

http://reviews.llvm.org/D5739

llvm-svn: 219860

CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.

Even if the definition was already emitted, it would never mark the
alias as thread_local.

This fixes PR21288.

llvm-svn: 219859

Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.

llvm-svn: 219857

coding conventions.  Lots of whitespace et al changes but no
content changes.

llvm-svn: 219856

This is fragile, as there are classes with the same name in both
namespaces (e.g. llvm::Module and clang::Module).

llvm-svn: 219855

Summary:
This is based on the discussions from the LLVMDev thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html

Reviewers: chandlerc

Reviewed By: chandlerc

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5389

llvm-svn: 219854

llvm-svn: 219853

llvm-svn: 219852

When performing a type deduction from the return type, the FunctionDecl may be
attributed with a calling convention.  In such a case, the retrieved type
location may be an AttributedTypeLoc.  Performing a castAs<FunctionProtoTypeLoc>
on such a type loc would result in an assertion as they are not derived types.

Ensure that we correctly handle the attributed type location by looking through
it to the modified type loc.

Fixes an assertion triggered in C++14 mode.

llvm-svn: 219851

Remove the use of an unnecessary function.  NFC.

llvm-svn: 219850

llvm-svn: 219849

The SelectDS1Addr1Offset complex pattern always tries to store constant
lds pointers in the offset operand and store a zero value in the addr operand.
Since the addr operand does not accept immediates, the zero value
needs to first be copied to a register.

This newly created zero value will not go through normal instruction
selection, so we need to manually insert a V_MOV_B32_e32 in the complex
pattern.

This bug was hidden by the fact that if there was another zero value
in the DAG that had not been selected yet, then the CSE done by the DAG
would use the unselected node for the addr operand rather than the one
that was just created.  This would lead to the zero value being selected
and the DAG automatically inserting a V_MOV_B32_e32 instruction.

llvm-svn: 219848

runOnMachineFunction.

llvm-svn: 219847

This original fix for the build break was correct.  LLVM_ATTRIBUTE_USED
removes the warning message because it keeps the function in the object
file.  LLVM_ATTRIBUTE_UNUSED indicates that it may or may not be used
depending on build settings.

llvm-svn: 219846

Store `User::NumOperands` (and `MDNode::NumOperands`) in `Value`.

On 64-bit host architectures, this reduces `sizeof(User)` and all
subclasses by 8, and has no effect on `sizeof(Value)` (or, incidentally,
on `sizeof(MDNode)`).

On 32-bit host architectures, this increases `sizeof(Value)` by 4.
However, it has no effect on `sizeof(User)` and `sizeof(MDNode)`, so the
only concrete subclasses of `Value` that actually see the increase are
`BasicBlock`, `Argument`, `InlineAsm`, and `MDString`.  Moreover, I'll
be shocked and confused if this causes a tangible memory regression.

This has no functionality change (other than memory footprint).

llvm-svn: 219845

A follow-up commit will modify the memory-layout of `Value`, `User`, and
`MDNode`.  First fix the comments to be doxygen-friendly (and to follow
the coding standards).

  - Use "\brief" instead of "repeatedName -".
  - Add a brief intro where it was missing.
  - Remove duplicated comments from source files (and a couple of
    noisy/trivial comments altogether).

llvm-svn: 219844

The bots were complaining (possibly because of a lack of traits on the iterator
I was trying to use). No functional change.

llvm-svn: 219843

After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it will actually affect ABI / class layout).

llvm-svn: 219842

llvm-svn: 219841

This change moves SanitizerBlacklist.h from lib/CodeGen
to public Clang headers in include/clang/Basic. SanitizerBlacklist
is currently only used in CodeGen to decide which functions/modules
should be instrumented, but this will soon change as ASan will
optionally modify class layouts during AST construction
(http://reviews.llvm.org/D5687). We need blacklist machinery
to be available at this point.

llvm-svn: 219840

PPC64/NetBSD.

llvm-svn: 219839

Use switch for FreeBSD check to allow easier extension.

llvm-svn: 219838

llvm-svn: 219837

Not all situations are representable in the compressed __unwind_info format,
and when this happens the entry needs to point to the more general __eh_frame
description.

Just x86_64 implementation for now.

rdar://problem/18208653

llvm-svn: 219836