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

llvm-svn: 246914

llvm-svn: 246913

llvm-svn: 246912

llvm-svn: 246911

llvm-svn: 246910

llvm-svn: 246909

llvm-svn: 246908

llvm-svn: 246906

We want a deterministic output. GNU AS leaves it zero.

FIXME: It may be optional by its user, like llc and clang.
llvm-svn: 246905

This commit accomplish two goals:
1) it's a step forward to deprecate macho-dump, now less than 40 tests
rely on it.

2) It tests all the MachO specific features introduced in llvm-readobj in
the following commits:  r246789, r246665, r246474.

While the conversion is mostly mechanical (I double-checked all the
tests output one by one, but still), a post-commit review is greatly
appreciated.

llvm-svn: 246904

llvm-svn: 246903

It wasn't obvious what the assembly was to generate these relocations, so I did the test with yaml.

llvm-svn: 246902

[elf2] Correctly handle sections with an alignment of 0. Spec says to treat it as an alignment of 1.

llvm-svn: 246901

PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from
an input pattern that looks like this:

  and(or(x, c1), c2)

but the associated logic does not work if there are bits that are 1 in c1 but 0
in c2 (these are normally canonicalized away, but that can't happen if the 'or'
has other users. Make sure we abort the transformation if such bits are
discovered.

Fixes PR24704.

llvm-svn: 246900

llvm-svn: 246899

The variable is actually called ANDROID_SERIAL.
This was not exercised on the bots until today.
Should fix the sanitizer-x86_64-linux failures.

llvm-svn: 246898

llvm-svn: 246897

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

llvm-svn: 246896

llvm-svn: 246895

Reviewers: chaoren

Subscribers: lldb-commits

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

llvm-svn: 246894

llvm-svn: 246893

llvm-svn: 246892

Tests need to be run either via asanwrapper or asanwrapper64
depending in the binary bitness. This matters when testing on an
aarch64 device.

llvm-svn: 246891

Apparently there are many cast kinds that may cause implicit pointer
arithmetic to happen. In light of this, the cast ignoring logic
introduced in r246877 has been changed to only ignore a small set of
cast kinds, and a test for this behavior has been added.

Thanks to Richard for catching this before it became a bug report. :)

llvm-svn: 246890

llvm-svn: 246889

llvm-svn: 246888

llvm-svn: 246887

llvm-svn: 246886

Summary: lldb::tid_t is 64 bit, but "long" need not always be 64 bit.

Reviewers: chying, clayborg

Subscribers: lldb-commits

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

llvm-svn: 246885

Add a --language (-l) option to type category {enable|disable} to allow people to turn on and off formatters for a given language

llvm-svn: 246884

We were crashing in CodeGen given input like this:

  int self_alias(void) __attribute__((weak, alias("self_alias")));

such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.

Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release.  However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.

Fixes PR23509.

llvm-svn: 246882