llvm-svn: 199934

loops. Writing back to the accumulator (231-type) allows the coalescer to
eliminate an extra copy.

llvm-svn: 199933

llvm-svn: 199932

llvm-svn: 199930

Eliminates the LLI_BUILDING_CHILD build hack from r199885.

Also add a FIXME to remove code that tricks the tests into passing when the
feature fails to work. Please don't do stuff like this, the tests exist for a
reason!

llvm-svn: 199929

Originally, BLX was passed as operand #0 in MachineInstr and as operand
#2 in MCInst. But now, it's operand #2 in both cases.

This patch also removes unnecessary FileCheck in the test case added by r199127.

llvm-svn: 199928

llvm-svn: 199927

This patch adds the target analysis passes (usually TargetTransformInfo) to the
codgen pipeline. We also expose now the AddAnalysisPasses method through the C
API, because the optimizer passes would also benefit from better target-specific
cost models.

Reviewed by Andrew Kaylor

llvm-svn: 199926

llvm-svn: 199925

void.

Patch by Scott Talbot.

llvm-svn: 199924

The declarations seem correct, but the definitions were using
chars instead of shorts.

llvm-svn: 199923

Clang says that "flow" is unused when building LLD. This patch suppresses it.

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

llvm-svn: 199922

This fixes a crash in the OpenCV OpenCL test suite.

There is no lit test for this, because the test would be very large
and could easily be invalidated by changes to the scheduler
or other parts of the compiler.

Patch by:  Vincent Lejeune

llvm-svn: 199919

This pattern uses an SDNodeXForm, which isn't being emitted for some
reason.  I can get it to work by attaching the PatLeaf that has the
XForm to the argument in the output pattern, but this results in an
immediate being used in a register operand, which the backend can't
handle yet.

llvm-svn: 199918

The control flow finalizer would sometimes use an ALU_POP_AFTER
instruction before the vetex fetch clause instead of using a POP
instruction after it.

llvm-svn: 199917

Implement the getUnrollingPreferences() function for
AMDGPUTargetTransformInfo so that loops that do address calculations
on pointers derived from alloca are unconditionally unrolled.

Unrolling these loops makes it more likely that SROA will be able to
eliminate the allocas, which is a big win for R600 since memory
allocated by alloca (private memory) is really slow.

llvm-svn: 199916

llvm-svn: 199915

the function size.

llvm-svn: 199914

llvm-svn: 199911

llvm-svn: 199910

Argument promotion can replace an argument of a call with an alloca. This
requires clearing the tail marker as it is very likely that the callee is now
using an alloca in the caller.

This fixes pr14710.

llvm-svn: 199909

This reverts Host.cpp LaunchProcess spawn behavior on FreeBSD to be
like Linux (and unlike OS X) with regards to how default signal
handlers and setup on the spawned process. FreeBSD does not reset
default signal handlers on the spawned process after this change.

llvm-svn: 199908

The tests (forgot to svn add, sorry!).

Patch from Fraser Cormack!

llvm-svn: 199907

Patch from Fraser Cormack!

llvm-svn: 199906

The unit test is now disabled on non-asserts builds.

The CF stack can be corrupted if you use CF_ALU_PUSH_BEFORE,
CF_ALU_ELSE_AFTER, CF_ALU_BREAK, or CF_ALU_CONTINUE when the number of
sub-entries on the stack is greater than or equal to the stack entry
size and sub-entries modulo 4 is either 0 or 3 (on cedar the bug is
present when number of sub-entries module 8 is either 7 or 0)

We choose to be conservative and always apply the work-around when the
number of sub-enries is greater than or equal to the stack entry size,
so that we can safely over-allocate the stack when we are unsure of the
stack allocation rules.

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199905

llvm-svn: 199904

llvm-svn: 199903

llvm-svn: 199902

llvm-svn: 199901

llvm-svn: 199900

[Sanitizer] Fix false positive in snprintf interceptor - take the number of actually written symbols from real snprintf call.

llvm-svn: 199899

llvm-svn: 199898

Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:

    for ( ; ({ if (first) { first = 0; continue; } 0; }); )

This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.

This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.

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

llvm-svn: 199897

This is a simpler rule, broadly in line with previous Darwin (which chose
between "soft" and "softfp") but probably safer. In practice the only real
reason for "softfp" is ABI compatibility, not usually an issue on limited chips
like these, so anyone who wanted hard-float should already be saying so.

That's my story and I'm sticking to it.

rdar://problem/15887493

llvm-svn: 199896

llvm-svn: 199895

llvm-svn: 199894

they give better sequences than VPERMI

llvm-svn: 199893

More universal way of removing trailing whitespace characters then 'chomp' does. Chomp "removes any trailing string that corresponds to the current value of $/" (quote from perldoc). In my case an input ended with '\r\r\n', chomp left '\r' at the end of input and the script ended up with an error "Use of uninitialized value in concatenation (.) or string"

llvm-svn: 199892

With constant-sharing, litpool loads consume 4 + N*2 bytes of code, but
movw/movt pairs consume 8*N. This means litpools are better than movw/movt even
with just one use. Other materialisation strategies can still be better though,
so the logic is a little odd.

llvm-svn: 199891

llvm-svn: 199890