(reduced LLVM IR) + (full source in comment)
with the
(full LLVM IR) + (reduced src in comment)

llvm-svn: 186119

llvm-svn: 186118

llvm-svn: 186110

We had patterns to match v4i32 immAllZerosV -> V_SET0, but not patterns for
v8i16 (which occurs in the test case) or v16i8. The same was true for
V_SETALLONES (so I added the associated patterns for those as well).

Another bug found by llvm-stress.

llvm-svn: 186108

Patch by Michele Scandale!

Adds a special handling of the case where, during the loop exit
condition rewriting, the exit value is a constant of bitwidth lower
than the type of the induction variable: instead of introducing a
trunc operation in order to match correctly the operand types, it
allows to convert the constant value to an equivalent constant,
depending on the initial value of the induction variable and the trip
count, in order have an equivalent comparison between the induction
variable and the new constant.

llvm-svn: 186107

This fixes a bug (found by csmith) at -O0 where we attempt to create a RLWIMI
with an out-of-range operand. Most uses of the isRunOfOnes function are guarded
by a condition that the value is not zero. This was not true in two places, and
in both places a zero input would result in an out-of-rage MB value (= 32).

To fix this, isRunOfOnes returns false on a zero input (and I've remove one
now-redundant guard).

llvm-svn: 186101

While at it, use strftime on Unix too and use the thread safe versions
of localtime.

llvm-svn: 186090

We can vectorize them because in the case where we wrap in the address space the
unvectorized code would have had to access a pointer value of zero which is
undefined behavior in address space zero according to the LLVM IR semantics.
(Thank you Duncan, for pointing this out to me).

Fixes PR16592.

llvm-svn: 186088

llvm-svn: 186084

in parallel.

llvm-svn: 186083

llvm-svn: 186082

llvm-svn: 186081

llvm-svn: 186074

Extend r186072 to handle shifts and ANDs.

llvm-svn: 186073

RISBG can handle some ANDs for which no AND IMMEDIATE exists.
It also acts as a three-operand AND for some cases where an
AND IMMEDIATE could be used instead.

It might be worth adding a pass to replace RISBG with AND IMMEDIATE
in cases where the register operands end up being the same and where
AND IMMEDIATE is smaller.

llvm-svn: 186072

RISBG has three 8-bit operands (I3, I4 and I5).  I'd originally
restricted all three to 6 bits, since that's the only range we intended
to use at the time.  However, the top bit of I4 acts as a "zero" flag for
RISBG, while the top bit of I3 acts as a "test" flag for RNSBG & co.
This patch therefore allows them to have the full 8-bit range.
I've left the fifth operand as a 6-bit value for now since the
upper 2 bits have no defined meaning.

llvm-svn: 186070

predecessors of the two blocks it is attempting to merge supply the
same incoming values to any phi in the successor block.  This change
allows merging in the case where there is one or more incoming values
that are undef.  The undef values are rewritten to match the non-undef
value that flows from the other edge.  Patch by Mark Lacey.

llvm-svn: 186069

When computing currently-live registers, the register scavenger excludes undef
uses. As a result, undef uses are ignored when computing the restore points of
registers spilled into the emergency slots. While the register scavenger
normally excludes from consideration, when scavenging, registers used by the
current instruction, we need to not exclude undef uses. Otherwise, we might end
up requiring more emergency spill slots than we have (in the case where the
undef use *is* the currently-spilled register).

Another bug found by llvm-stress.

llvm-svn: 186067

llvm-svn: 186063

llvm-svn: 186062

llvm-svn: 186060

Without the changes introduced into this patch, if TRE saw any allocas at all,
TRE would not perform TRE *or* mark callsites with the tail marker.

Because TRE runs after mem2reg, this inadequacy is not a death sentence. But
given a callsite A without escaping alloca argument, A may not be able to have
the tail marker placed on it due to a separate callsite B having a write-back
parameter passed in via an argument with the nocapture attribute.

Assume that B is the only other callsite besides A and B only has nocapture
escaping alloca arguments (*NOTE* B may have other arguments that are not passed
allocas). In this case not marking A with the tail marker is unnecessarily
conservative since:

  1. By assumption A has no escaping alloca arguments itself so it can not
     access the caller's stack via its arguments.

  2. Since all of B's escaping alloca arguments are passed as parameters with
     the nocapture attribute, we know that B does not stash said escaping
     allocas in a manner that outlives B itself and thus could be accessed
     indirectly by A.

With the changes introduced by this patch:

  1. If we see any escaping allocas passed as a capturing argument, we do
     nothing and bail early.

  2. If we do not see any escaping allocas passed as captured arguments but we
     do see escaping allocas passed as nocapture arguments:

       i. We do not perform TRE to avoid PR962 since the code generator produces
          significantly worse code for the dynamic allocas that would be created
          by the TRE algorithm.

       ii. If we do not return twice, mark call sites without escaping allocas
           with the tail marker. *NOTE* This excludes functions with escaping
           nocapture allocas.

  3. If we do not see any escaping allocas at all (whether captured or not):

       i. If we do not have usage of setjmp, mark all callsites with the tail
          marker.

       ii. If there are no dynamic/variable sized allocas in the function,
           attempt to perform TRE on all callsites in the function.

Based off of a patch by Nick Lewycky.

rdar://14324281.

llvm-svn: 186057

I had thought that these tests could be target-neutral, but in practice this is
not the case (on some targets, like Hexagon and Darwin), they trigger an assert
(a different assert than the one that r186044 fixes).

llvm-svn: 186051

Trying to fix the i686-mingw32 build.

llvm-svn: 186046

For some reason, the Hexagon backend does not reject these invalid static
initializer expressions, but instead crashes in AsmPrinter::EmitGlobalConstant.

llvm-svn: 186045

A non-constant-foldable static initializer expression containing insertvalue or
extractvalue had been causing an assert:

  Constants.cpp:1971: Assertion `FC && "ExtractValue constant expr couldn't be
                                 folded!"' failed.

Now we report a more-sensible "Unsupported expression in static initializer"
error instead.

Fixes PR15417.

llvm-svn: 186044

It is not reliable to depend on the output of llvm_unreachable. The original
change will have proper tests when llvm-ar moves to lib/Object (soon).

llvm-svn: 186043

llvm-svn: 186041

There is no lib/Archive anymore and some archive tests were in test/Archive and
others in test/Object. Since archive is just one of the formats supported by
lib/Object, test/Object is probably the best location.

llvm-svn: 186038

llvm-svn: 186035

Patch from Игорь Пашев  (I do hope we support utf-8 commit messages; I
also hope he'll forgive me for transliterating it as Igor Pashev in
case things go horribly wrong).

llvm-svn: 186034

llvm-svn: 186031

llvm-svn: 186029

llvm-svn: 186027

Enough for the radeonsi driver to use it for calculating derivatives.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186012

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186010

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186008

llvm-svn: 186001

llvm-svn: 185999

Pulled in a testcase from the debuginfo-test suite.

llvm-svn: 185993