The tests are refactored to use the same fixture.

llvm-svn: 204860

This commit consist of two parts.
The first part fix the PR15967. The wrong conclusion was made when the MaxLookup
limit was reached. The fix introduce a out parameter (MaxLookupReached) to
DecomposeGEPExpression that the function aliasGEP can act upon.
The second part is introducing the constant MaxLookupSearchDepth to make sure
that DecomposeGEPExpression and GetUnderlyingObject use the same search depth.
This is a small cleanup to clarify the original algorithm.

Patch by Karl-Johan Karlsson!

llvm-svn: 204859

llvm-svn: 204857

Makes sure the Call dies before the Function

llvm-svn: 204856

llvm-svn: 204855

Expose the number of DFSan labels allocated by adding function dfsan_get_label_count().

Patch by Sam Kerner!

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

llvm-svn: 204854

llvm-svn: 204853

selectors because we were not going through entire
elements in list of all implemented selectors. 
// rdar://16428638

llvm-svn: 204852

In CallInst, op_end() points at the callee, which we don't want to iterate over
when just iterating over arguments. Now take this into account when returning
a iterator_range from arg_operands. Similar reasoning for InvokeInst.

Also adds a unit test to verify this actually works as expected.

llvm-svn: 204851

Use <mutex> instead of "llvm/Support/Mutex.h".

Also change the type of mutex for the context object to recursive mutex, as
the driver could acquire the lock recursively. E.g. If file A has .drectve
section containing /defaultlib:B, the driver tries to parse file B, and if
file B has .drectve section, the driver acquires the lock again.

llvm-svn: 204850

This commit also adds tests for std::numeric_limits<__[u]int128_t>.

Reviewed in http://llvm-reviews.chandlerc.com/D2917

llvm-svn: 204849

I've not yet updated PPCTTI because I'm not sure what the actual relative cost
is compared to the aligned uses.

llvm-svn: 204848

size 16 double-spaced registers instruction printing.

This:
	vld4.16 {d17[1], d19[1], d21[1], d23[1]}, [r7]!

was being printed as:

	vld4.16 {d17[1], d18[1], d19[1], d20[1]}, [r7]!

rdar://16435096

llvm-svn: 204847

llvm-svn: 204846

llvm-svn: 204845

We're already effectively checking sanity for that in PBQP::Graph::addEdge.

llvm-svn: 204844

llvm-svn: 204843

Edit by Daniel Fahlgren.

llvm-svn: 204842

The edge data structure (EdgeEntry) now holds the indices of its entries in the
adjacency lists of the nodes it connects. This trades a little ugliness for
faster insertion/removal, which is now O(1) with a cheap constant factor. All
of this is implementation detail within the PBQP graph, the external API remains
unchanged.

Individual register allocations are likely to change, since the adjacency lists
will now be ordered differently (or rather, will now be unordered). This
shouldn't affect the average quality of allocations however.

llvm-svn: 204841

This sext_inreg i32 in i64 case was already handled, but not enabled.

llvm-svn: 204840

These patterns are dead (because v4f32 stores are currently promoted to v4i32
and stored using Altivec instructions), and also are likely not correct
(because they'd store the vector elements in the opposite order from that
assumed by the rest of the Altivec code).

llvm-svn: 204839

These instructions have access to the complete VSX register file. In addition,
they "swap" the order of the elements so that element 0 (the scalar part) comes
first in memory and element 1 follows at a higher address.

llvm-svn: 204838

llvm-svn: 204837

Similar to r204835

llvm-svn: 204836

This patch is in similar vein to what done earlier to Module::globals/aliases
etc. It allows to iterate over function arguments like this:

  for (Argument Arg : F.args()) {
    ...
  }

llvm-svn: 204835

This commit fixes a cast instruction assertion failure
due to the incompatible type cast.  This will only happen when
the target requires atomic libcalls.

llvm-svn: 204834

In some cases it is possible for CGP to attempt to reuse a base address from
another basic block. In those cases we have to be sure that all the address
math was either done at the same bit width, or that none of it overflowed
before it was extended.

Patch by Louis Gerbarg <lgg@apple.com>

rdar://16307442

llvm-svn: 204833

Add M_ZERO awareness to malloc() static analysis in Clang for FreeBSD,
NetBSD, and OpenBSD in a similar fashion to O_CREAT for open(2).
These systems have a three-argument malloc() in the kernel where the
third argument contains flags; the M_ZERO flag will zero-initialize the
allocated buffer.

This should reduce the number of false positives when running static
analysis on BSD kernels.

Additionally, add kmalloc() (Linux kernel malloc()) and treat __GFP_ZERO
like M_ZERO on Linux.

Future work involves a better method of checking for named flags without
hardcoding values.

Patch by Conrad Meyer, with minor modifications by me.

llvm-svn: 204832

Hopefully addresses r204539.

Make clang/test/lit.cfg pre-scan the RUN line looking for tool names,
and substitute fully qualified path names pointing to the build
directory.  This ensures we're testing the just-built tools.

llvm-svn: 204831

Review : http://llvm-reviews.chandlerc.com/D3182

llvm-svn: 204830

>  For functions where esi is used as base pointer, we would previously fall ba
>  from lowering memcpy with "rep movs" because that clobbers esi.
>
>  With this patch, we just store esi in another physical register, and restore
>  it afterwards. This adds a little bit of register preassure, but the more
>  efficient memcpy should be worth it.
>
>  Differential Revision: http://llvm-reviews.chandlerc.com/D2968

This didn't work. I was ending up with code like this:

  lea     edi,[esi+38h]
  mov     ecx,0Fh
  mov     edx,esi
  mov     esi,ebx
  rep movs dword ptr es:[edi],dword ptr [esi]
  lea     ecx,[esi+74h] <-- Ooops, we're now using esi before restoring it from edx.
  add     ebx,3Ch
  mov     esi,edx

I guess if we want to do this we need stronger glue or something, or doing the expansion
much later.

llvm-svn: 204829

v2i64 needs to be a legal VSX type because it is the SetCC result type from
v2f64 comparisons. We need to expand all non-arithmetic v2i64 operations.

This fixes the lowering for v2f64 VSELECT.

llvm-svn: 204828

llvm-svn: 204827

This enables TableGen to generate an additional two operand matcher
for our ArithLogicR class of instructions (constituted by 3 register operands).
E.g.: and $1, $2 <=> and $1, $1, $2

llvm-svn: 204826

Fixes PR19253.

llvm-svn: 204825

llvm-svn: 204824

The interceptors had code that after macro expansion ended up looking like

extern "C" void memalign()
    __attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
    __attribute__((alias("memalign")));

That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign

Both gcc and clang produce assembly that look like

__interceptor_memalign:
...
        .weak   memalign
memalign = __interceptor_memalign
        .globl  __interceptor___libc_memalign
__interceptor___libc_memalign = memalign

What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:

     8: 0000000000000000     1 FUNC    GLOBAL DEFAULT    1
__interceptor_memalign
     9: 0000000000000000     1 FUNC    WEAK   DEFAULT    1 memalign
    10: 0000000000000000     1 FUNC    GLOBAL DEFAULT    1
__interceptor___libc_memalign

In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as

extern "C" void memalign()
    __attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
    __attribute__((alias("__interceptor_memalign")));

If nothing else, this patch makes it more obvious what is going on.

llvm-svn: 204823

The '.dword' directive accepts a list of expressions and emits
them in 8-byte chunks in successive locations.

llvm-svn: 204822

The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.

__va_end and __va_arg are not needed.

llvm-svn: 204821

Adding the mapping between __builtin___clear_cache into @llvm.clear_cache

llvm-svn: 204820