Seems that the patch was rebased on top of another change which obsoleted the
change but wasnt caught.

Thanks to nbjoerg for pointing this out!

llvm-svn: 258821

llvm-svn: 258820

llvm-svn: 258819

No functional change, just moving code around.

llvm-svn: 258818

Summary:
This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others).

Reviewers: ABataev

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

llvm-svn: 258817

This is a step towards solving PR25892:
https://llvm.org/bugs/show_bug.cgi?id=25892

It won't handle the reported case. As noted by the 'TODO' comments in the patch, 
we need to relax the hasOneUse() constraint and also match patterns that include
memset_chk() and the llvm.memset() intrinsic in addition to memset().

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

llvm-svn: 258816

This reverts commit r258814.

llvm-svn: 258815

Support for the -fno-math-builtin option was added in r186899.  The codegen side
is being tested in test/CodeGen/nomathbuiltin.c.  The missing part was just
passing the option through the driver.

PR26317

llvm-svn: 258814

The actual fix should be addressed by someone who can test on Darwin.

llvm-svn: 258813

This commit exposes a crash in computeKnownBits on the Chromium buildbots.
Reverting to investigate.

Reference: https://llvm.org/bugs/show_bug.cgi?id=26307
llvm-svn: 258812

Originally this change was causing failures on windows buildbots.
But those problems were fixed in r258806.

llvm-svn: 258811

llvm-svn: 258810

Ensure that there is at most one phi write access per PHINode and
ScopStmt. In particular, this would be possible for non-affine
subregions with multiple exiting blocks. We replace multiple MAY_WRITE
accesses by one MUST_WRITE access. The written value is constructed
using a PHINode of all exiting blocks. The interpretation of the PHI
WRITE's "accessed value" changed from the incoming value to the PHI like
for PHI READs since there is no unique incoming value.

Because region simplification shuffles around PHI nodes -- particularly
with exit node PHIs -- the PHINodes at analysis time does not always
exist anymore in the code generation pass. We instead remember the
incoming block/value pair in the MemoryAccess.

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

llvm-svn: 258809

Keep at most one value read MemoryAccess per value and statement;
multiple generated loads do not have any additional effect. As one such
MemoryAccess can cater multiple uses within the statement, the
AccessInstruction property is not unique any more and set to nullptr.

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

llvm-svn: 258808

Ensure there is at most one write access per definition of an
llvm::Value. Keep track of already created value write access by using
a (dense) map.

Replace addValueWriteAccess by ensureValueStore which can be uses more
liberally without worrying to add redundant accesses. It will be used,
e.g. in a logical correspondant for value reads -- ensureValueReload --
to ensure that the expected definition has been written when loading it.

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

llvm-svn: 258807

We can't rely on the evalution order of function arguments.

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

llvm-svn: 258806

OpenMP 4.5, alogn with array sections, allows to use variables of array type in reductions.

llvm-svn: 258804

llvm-svn: 258803

llvm-svn: 258802

Summary: Fix the assertion failure for the user-defined conversion method. e.g.: operator bool()

Reviewers: alexfh, aaron.ballman

Subscribers: aaron.ballman, cfe-commits

Patch by Cong Liu!

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

llvm-svn: 258801

Patch replaces the 'renderscript allocation list' command flag --refresh, with a new option --id <ID>.
This new option only prints the details of a single allocation with a given id, rather than printing all the allocations.
Functionality from the removed '--refresh' flag will be moved into its own command in a subsequent commit.

llvm-svn: 258800

Both functions implement the same functionality, with the difference that
getNewScalarValue assumes that globals and out-of-scop scalars can be directly
reused without loading them from their corresponding stack slot. This is correct
for sequential code generation, but causes issues with outlining code e.g. for
OpenMP code generation. getNewValue handles such cases correctly.

Hence, we can replace getNewScalarValue with getNewValue. This is not only more
future proof, but also eliminates a bunch of code.

The only functionality that was available in getNewScalarValue that is lost
is the on-demand creation of scalar values. However, this is not necessary any
more as scalars are always loaded at the beginning of each basic block and will
consequently always be available when scalar stores are generated. As this was
not the case in older versions of Polly, it seems the on-demand loading is just
some older code that has not yet been removed.

Finally, generateScalarLoads also generated loads for values that are loop
invariant, available in GlobalMap and which are preferred over the ones loaded
in generateScalarLoads. Hence, we can just skip the code generation of such
scalar values, avoiding the generation of dead code.

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

llvm-svn: 258799

This patch adds support for trailing zero elements to VZEXT_LOAD loads (and checks that no zero elts occur within the consecutive load).

It also generalizes the 64-bit VZEXT_LOAD load matching to work for loads other than 2x32-bit loads.

After this patch it will also be easier to add support for other basic load patterns like 32-bit VZEXT_LOAD loads, PMOVZX and subvector load insertion.

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

llvm-svn: 258798

llvm-svn: 258797

llvm-svn: 258796

llvm-svn: 258795

llvm-svn: 258794

Their opcodes are used as part of the VEX prefix in 64-bit mode. Clearly the disassembler implicitly decoded them as AVX instructions in 64-bit mode, but I think the AsmParser would have encoded them.

llvm-svn: 258793

This new code should be logically equivalent to the previous code.

llvm-svn: 258792

llvm-svn: 258791

llvm-svn: 258790

Make comments and indentation more consistent.

Rearrange a few things to be in a more consistent order,
such as organizing subtarget features from those describing
an actual device property, and those used as options.

llvm-svn: 258789

Old intrinsics were forcing these, but they have now all
been removed. This fixes large i8 vector operations generally
being broken.

llvm-svn: 258788

I did my best to try to update all the uses in tests that
just happened to use the old ones to the newer intrinsics.

I'm not sure I got all of the immediate operand conversions
correct, since the value seems to have been ignored by the
old pattern but I don't think it really matters.

llvm-svn: 258787

More cleanup to try to get all intrinsics using the correct
amdgcn prefix that are as close to the instruction as possible.

llvm-svn: 258786

Some of the special intrinsics now that now correspond to a instruction
also have special setting of some registers, e.g. llvm.SI.sendmsg sets
m0 as well as use s_sendmsg. Using these explicit register intrinsics
may be a better option.

Reading the exec mask and others may be useful for debugging. For this
I'm not sure this is entirely correct because we would want this to
be convergent, although it's possible this is already treated
sufficently conservatively.

llvm-svn: 258785

llvm-svn: 258784

Also move into backend intrinsics to discourage use of the old name.

llvm-svn: 258783

Fix arc patch fuzz error.
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.

Reviewers: Anastasia, pekka.jaaskelainen

Subscribers: keryell, bader, cfe-commits

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

llvm-svn: 258782

These calls return their first argument, but because LLVM uses an intrinsic
with a void return type, they can't use the returned attribute. Generalize
the store results pass to optimize these calls too.

llvm-svn: 258781