llvm-svn: 246954

llvm-svn: 246953

llvm-svn: 246952

llvm-svn: 246951

llvm-svn: 246950

llvm-svn: 246949

Transferred SSSE3 instructions from sse-builtins.c

llvm-svn: 246948

Transferred SSE41 instructions from sse-builtins.c

llvm-svn: 246947

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

llvm-svn: 246946

llvm-svn: 246945

llvm-svn: 246944

Only works for avx512f (dq) targets so far - need to add avx512bw tests once char/short shifts are supported.

llvm-svn: 246943

Our alias metadata is currently not emitted in a deterministic order. As it
is not needed in this test, we just drop it for now (but keep in mind to fix
this).

llvm-svn: 246942

When this option is enabled, Polly will emit printf calls for each scalar
load/and store which dump the scalar value loaded/stored at run time.

This patch also refactors the RuntimeDebugBuilder to use variadic templates
when generating CPU printfs. As result, it now becomes easier to print
strings that consist of a set of arguments. Also, as a single printf
call is emitted, it is more likely for such strings to be emitted atomically
if executed multi-threaded.

llvm-svn: 246941

llvm-svn: 246940

Trivial multiplication by zero may survive the worklist.  We tried to
reassociate the multiplication with a division instruction, causing us
to divide by zero; bail out instead.

This fixes PR24726.

llvm-svn: 246939

In searching for a fix for the underlying code-quality bug highlighted by
r246937 (that SDAG simplification can lead to us generating an ISD::OR node
with a constant zero LHS), I ran across this:

We generically canonicalize commutative binary-operation nodes in SDAG getNode
so that, if only one operand is a constant, it will be on the RHS.  However, we
were doing this only after a bunch of constant-based simplification checks that
all assume this canonical form (that any constant will be on the RHS). Moving
the operand-swapping canonicalization prior to these checks seems like the
right thing to do (and, as it turns out, causes SDAG to completely fold away the
computation in test/CodeGen/ARM/2012-11-14-subs_carry.ll, just like InstCombine
would do).

llvm-svn: 246938

To commute a trivial rlwimi instructions (meaning one with a full mask and zero
shift), we'd need to ability to form an all-zero mask (instead of an all-one
mask) using rlwimi. We can't represent this, however, and we'll miscompile code
if we try.

The code quality problem that this highlights (that SDAG simplification can
lead to us generating an ISD::OR node with a constant zero LHS) will be fixed
as a follow-up.

Fixes PR24719.

llvm-svn: 246937

llvm-svn: 246936

Summary:
Update the Go bindings to DIBuilder to match
the split of creating local variables into
auto and parameter variables.

Reviewers: pcc

Subscribers: llvm-commits, axw

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

llvm-svn: 246935

llvm-svn: 246934

This fixes PR24713.

llvm-svn: 246933

llvm-svn: 246932

Expose the previously unexposed visibility attribute via the python and C
bindings.

llvm-svn: 246931

Differential: http://reviews.llvm.org/D11590
llvm-svn: 246930

Some of the structures are renamed, subfunction introduced to clarify the
individual steps and comments are added describing their functionality.

llvm-svn: 246929

In the common case, the access functions are not modified, hence there is no
need to obtain the IslAstBuild context at all. This should not only be minimally
faster, but this also allows the IslNodeBuilder to work on asts that are not
annotated with isl_ast_builds as long as the memory accesses are not modified.

llvm-svn: 246928

llvm-svn: 246927

By inspection the update of the GlobalMaps in the RegionGenerator seems unneed,
and is removed as also no test cases fail when dropping this. Johannes Doerfert
confirmed that this is indeed save:

"I think that code was needed when we did not use the scalar codegen by default.
Now everything defined in a non-affine region should be communicated via memory
and reloaded in the user block. Hence, we should be good removing this code."

llvm-svn: 246926

llvm-svn: 246925

llvm-svn: 246924

When computing the index expressions for new, multi-dimensional memory accesses
these new index expressions may reference original llvm::Values that are not
transfered into the OpenMP subfunction. Using GlobalMap we now replace
references to such values with the rewritten values that have e.g. been passed
to the OpenMP subfunction.

llvm-svn: 246923

llvm-svn: 246922

llvm-svn: 246921

The GlobalMap variable used in BlockGenerator should always reference the same
list througout the entire code generation, hence we can make it a member
variable to avoid passing it around through every function call.

History: Before we switched to the SCEV based code generation the GlobalMap
also contained a mapping form old to new induction variables, hence it was
different for each ScopStmt, which is why we passed it as function argument
to copyStmt. The new SCEV based code generation now uses a separate mapping
called LTS -> LoopToSCEV that maps each original loop to a new loop iteration
variable provided as a SCEVExpr. The GlobalMap is currently mostly used for
OpenMP code generation, where references to parameters in the original function
need to be rewritten to the locations of these variables after they have been
passed to the subfunction.

Suggested-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 246920

[mips][microMIPS] Implement ADD.fmt, SUB.fmt, MOV.fmt, MUL.fmt, DIV.fmt, MADDF.fmt, MSUBF.fmt and NEG.fmt instructions
Differential Revision: http://reviews.llvm.org/D11978

llvm-svn: 246919

Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.

We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.

add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.

llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.

One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.

Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
 - link all tools and shared libraries to libLLVM if
   LLVM_LINK_LLVM_DYLIB is set
 - some way of explicitly *not* doing so for utilities
   and libLLVM itself
Suggestions for improvement here are particularly welcome.

Reviewers: beanz

Subscribers: llvm-commits

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

llvm-svn: 246918

Originally, we disallowed the import of multi-dimensional access functions due
to our code generation not supporting the generation of new address expressions
for multi-dimensional memory accesses. When building our run-time alias check
infrastructure we added code generation support for multi-dimensional address
calculations.  Hence, we can now savely allow the import of new
multi-dimensional access functions.

llvm-svn: 246917

llvm-svn: 246916

llvm-svn: 246915