This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).

This hopefully removes for good the last include of LLVM's config.h.

llvm-svn: 210313

This patch can identify 
  ABS(X) ==> (X >s 0) ? X : -X and (X >s -1) ? X : -X
  ABS(X) ==> (X <s 0) ? -X : X and (X <s 1) ? -X : X
  NABS(X) ==> (X >s 0) ? -X : X and (X >s -1) ? -X : X
  NABS(X) ==> (X <s 0) ? X : -X and (X <s 1) ? X : -X
  
and can transform
  ABS(ABS(X)) -> ABS(X)
  NABS(NABS(X)) -> NABS(X)
  
Differential Revision: http://reviews.llvm.org/D3658

llvm-svn: 210312

The option check was being performed after config.h/llvm-config.h substitution,
generating incorrect macro definitions.

Fixes PR19614.

llvm-svn: 210311

If we have common uses on separate paths in the tree; process the one with greater common depth first.
This makes sure that we do not assume we need to extract a load when it is actually going to be part of a vectorized tree.

Review: http://reviews.llvm.org/D3800
llvm-svn: 210310

clang's own CMake setup handles this as of r210308.

The CMAKE_CROSSCOMPILING special-case will no longer be hard-coded. This was
clearly site-specific to someone's local configuration and should be passed in
at configure time if needed with e.g. -DLIBXML2_LIBRARIES=... (the libxml2
target I tried here doesn't even support liblzma so it's *way* off).

llvm-svn: 210309

This is clang's business and LLVM will soon be updated not to perform the check
for us.

llvm-svn: 210308

These had no business in LLVM core.

llvm-svn: 210307

llvm-svn: 210306

llvm-svn: 210305

PR11306 - Variadic template fix-it suggestion. Recover from misplaced or redundant ellipsis in parameter pack.

llvm-svn: 210304

llvm-svn: 210303

Alias with unnamed_addr were in a strange state. It is stored in GlobalValue,
the language reference talks about "unnamed_addr aliases" but the verifier
was rejecting them.

It seems natural to allow unnamed_addr in aliases:

* It is a property of how it is accessed, not of the data itself.
* It is perfectly possible to write code that depends on the address
of an alias.

This patch then makes unname_addr legal for aliases. One side effect is that
the syntax changes for a corner case: In globals, unnamed_addr is now printed
before the address space.

llvm-svn: 210302

llvm-svn: 210301

llvm-svn: 210300

llvm-svn: 210299

We extended the .section syntax to allow multiple sections with the
same name but different comdats, but currently we don't make sure that
the output section has that comdat symbol.

That happens to work with the code llc produces currently because it looks like

.section secName, "dr", one_only, "COMDATSym"
.globl COMDATSym
COMDATSym:
....

but that is not very friendly to anyone coding in assembly or even to
llc once we get comdat support in the IR.

This patch changes the coff object writer to make sure the comdat symbol is
output just after the section symbol, as required by the coff spec.

llvm-svn: 210298

Chandler correctly pointed out that I need an LLVM IR test for
r210282, which modified the vperm -> shuffle transform for little
endian PowerPC.  This patch provides that test.

llvm-svn: 210297

llvm-svn: 210296

Let's just go ahead and assume the answer was 'I do'

llvm-svn: 210295

Instead of disembodied diagnostics when debug info is disabled it's now
possible to identify the associated function's location in order to provide
some amount of of context.

We use the definition's body right brace location to differentiate the fallback
from diagnostics that genuinely relate to the function declaration itself (a
convention also used by gcc).

llvm-svn: 210294

Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.

This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.

An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.

llvm-svn: 210293

we can just pass in the values we already know and we're not
caching the subtarget anymore.

llvm-svn: 210292

Most issues are on mishandling s/zext.

Fixes:

1. When rebuilding new indices, s/zext should be distributed to
sub-expressions. e.g., sext(a +nsw (b +nsw 5)) = sext(a) + sext(b) + 5 but not
sext(a + b) + 5. This also affects the logic of recursively looking for a
constant offset, we need to include s/zext into the context of the searching.

2. Function find should return the bitwidth of the constant offset instead of
always sign-extending it to i64.

3. Stop shortcutting zext'ed GEP indices. LLVM conceptually sign-extends GEP
indices to pointer-size before computing the address. Therefore, gep base,
zext(a + b) != gep base, a + b

Improvements:

1. Add an optimization for splitting sext(a + b): if a + b is proven
non-negative (e.g., used as an index of an inbound GEP) and one of a, b is
non-negative, sext(a + b) = sext(a) + sext(b)

2. Function Distributable checks whether both sext and zext can be distributed
to operands of a binary operator. This helps us split zext(sext(a + b)) to
zext(sext(a) + zext(sext(b)) when a + b does not signed or unsigned overflow.

Refactoring:

Merge some common logic of handling add/sub/or in find.

Testing:

Add many tests in split-gep.ll and split-gep-and-gvn.ll to verify the changes
we made.

llvm-svn: 210291

llvm-svn: 210290

it's already on the subtarget.

llvm-svn: 210289

llvm-svn: 210288

I noticed that a proposed optimization would have prevented this.

llvm-svn: 210287

correct severity.

Previously all inline-asm diagnostics were reported as errors.

llvm-svn: 210286

This is a first step in seeing if it is possible to make llvm-nm produce
the same output as darwin's nm(1).  Darwin's default format is bsd but its
-m output prints the longer Mach-O specific details.  For now I added the
"-format darwin" to do this (whos name may need to change in the future).
As there are other Mach-O specific flags to nm(1) which I'm hoping to add some
how in the future.  But I wanted to see if I could get the correct output for
-m flag using llvm-nm and the libObject interfaces.

I got this working but would love to hear what others think about this approach
to getting object/format specific details printed with llvm-nm.

llvm-svn: 210285

Summary:
This change generalizes the code used to create global LLVM
variables referencing predefined strings (e.g. __FUNCTION__): now it
just calls GetAddrOfConstantStringFromLiteral method. As a result,
global variables for these predefined strings may get mangled names
and linkonce_odr linkage. Fix the test accordingly.

Test Plan: clang regression tests

Reviewers: majnemer

Reviewed By: majnemer

Subscribers: cfe-commits

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

llvm-svn: 210284

than omitting it the first time we see a decltype type with a particular
expression.

llvm-svn: 210283

As discussed in cfe commit r210279, the correct little-endian
semantics for the vec_perm Altivec interfaces are implemented by
reversing the order of the input vectors and complementing the permute
control vector.  This converts the desired permute from little endian
element order into the big endian element order that the underlying
PowerPC vperm instruction uses.  This is represented with a
ppc_altivec_vperm intrinsic function.

The instruction combining pass contains code to convert a
ppc_altivec_vperm intrinsic into a vector shuffle operation when the
intrinsic has a permute control vector (mask) that is a constant.
However, the vector shuffle operation assumes that vector elements are
in natural order for their endianness, so for little endian code we
will get the wrong result with the existing transformation.

This patch reverses the semantic change to vec_perm that was performed
in altivec.h by once again swapping the input operands and
complementing the permute control vector, returning the element
ordering to little endian.

The correctness of this code is tested by the new perm.c test added in
a previous patch, and by other tests in the test suite that fail
without this patch.

llvm-svn: 210282

llvm-svn: 210281

Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute.
It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables.

This also adds backend support for generating the jump-instruction tables on ARM and X86.
Note that since the jumptable attribute creates a second function pointer for a
function, any function marked with jumptable must also be marked with unnamed_addr.

llvm-svn: 210280

The PowerPC vperm (vector permute) instruction is defined
architecturally with a big-endian bias, in that the two input vectors
are assumed to be concatenated "left to right" and the elements of the
combined input vector are assumed to be numbered from "left to right"
(i.e., with element 0 referencing the high-order element).  This
definition is unnatural for little-endian code generation.

To facilitate ease of porting, the vec_perm interface is designed to
use natural element ordering, so that elements are numbered according
to little-endian design principles when code is generated for a
little-endian target.  The desired semantics can be achieved with the
vperm instruction provided that the two input vector registers are
reversed, and the permute control vector is complemented.  The
complementing is performed using an xor with a vector containing all
one bits.

Only the rightmost 5 bits of each element of the permute control
vector are relevant, so it would be possible to complement the vector
with respect to a <16xi8> vector containing all 31s.  However, when
the permute control vector is not a constant, using 255 instead has
the advantage that the vec_xor can be recognized during code
generation as a vnor instruction.  (Power8 introduces a vnand
instruction which could alternatively be generated.)

The correctness of this code is tested by the new perm.c test added in
a previous patch.  I plan to later make the existing ppc32 Altivec
compile-time tests work for ppc64 and ppc64le as well.

llvm-svn: 210279

Summary:
Add hasLocalStorage/hasGlobalStorage matchers for VarDecl nodes.
Update the doc. Also add them to the dynamic registry.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 210278

llvm-svn: 210275

This patch adds support for pointer types in global named registers variables.
It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls.
Also adds some early checks on types on SemaDecl to avoid the assert.

Tests changed accordingly. (PR19837)

llvm-svn: 210274

llvm-svn: 210273

Tests $Z0 and $z0.  Extends test exe get-code-address-hex:
to take a function name.

Enabled for debugserver, disabled for llgs.  Implementing
in llgs branch next.

llvm-svn: 210272