When building executables for Cray supercomputers, statically-linked executables
are preferred. This patch makes it possible to build the OpenMP runtime as an
archive for building statically-linked executables.  The patch adds the flag
LIBOMP_ENABLE_SHARED, which defaults to true. When true, a build of the OpenMP
runtime yields dynamic libraries. When false, a build of the OpenMP runtime
yields static libraries. There is no setting that allows both kinds of libraries
to be built.

Patch by John Mellor-Crummey

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

llvm-svn: 259817

Choose between MOVD/MOVSS and MOVQ/MOVSD depending on the target vector type.

This has a lot fewer test changes than trying to add this to X86InstrInfo::setExecutionDomain.....

llvm-svn: 259816

When SCEV expansion tries to reuse an existing value, it is needed to ensure
that using the Value at the InsertPt will not break LCSSA. The fix adds a
check that InsertPt is either inside the candidate Value's parent loop, or
the candidate Value's parent loop is nullptr.

llvm-svn: 259815

llvm-svn: 259814

  Add interfaces to do value profile data IR annnotation
  and read. Needed by both FE and IR based PGO.

llvm-svn: 259813

This patch allows the mixing of scaled and unscaled load/stores to form
load/store pairs.

PR24465
http://reviews.llvm.org/D12116
Many thanks to Ahmed and Michael for fixes and code review.

This is a reapplication of r246769 and r259790.  The tramp3d failure was caused
by an incorrect refactoring in the patch.  Specifically, we weren't always
properly clearing the SExtIdx flag.

llvm-svn: 259812

This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.

Review: http://reviews.llvm.org/D16730
llvm-svn: 259811

Summary:
While evaluating expressions when stopped in a class method, there was a
problem of member variables hiding local variables. This was happening
because, in the context of a method, clang already knew about member
variables with their name and assumed that they were the only variables
with those names in scope. Consequently, clang never checks with LLDB
about the possibility of local variables with the same name and goes
wrong. This change addresses the problem by using an artificial
namespace "$__lldb_local_vars". All local variables in scope are
declared in the "$__lldb_expr" method as follows:

    using $__lldb_local_vars::<local var 1>;
    using $__lldb_local_vars::<local var 2>;
    ...

This hides the member variables with the same name and forces clang to
enquire about the variables which it thinks are declared in
$__lldb_local_vars. When LLDB notices that clang is enquiring about
variables in $__lldb_local_vars, it looks up local vars and conveys
their information if found. This way, member variables do not hide local
variables, leading to correct evaluation of expressions.

A point to keep in mind is that the above solution does not solve the
problem for one specific case:

    namespace N
    {
        int a;
    }

    class A
    {
    public:
        void Method();
        int a;
    };

    void
    A::Method()
    {
        using N::a;
        ...

        // Since the above solution only touches locals, it does not
        // force clang to enquire about "a" coming from namespace N.
    }

Reviewers: clayborg, spyffe

Subscribers: lldb-commits

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

llvm-svn: 259810

llvm-svn: 259809

This doesn't attempt to move every decorator.  The reason for
this is that it requires touching every single test file to import
decorators.py.  I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.

llvm-svn: 259807

llvm-svn: 259806

llvm-svn: 259805

llvm-svn: 259804

llvm-svn: 259802

During instruction selection, the AArch64 backend can recognise the
following pattern and generate an [U|S]MADDL instruction, i.e. a
multiply of two 32-bit operands with a 64-bit result:

(mul (sext i32), (sext i32))
However, when one of the operands is constant, the sign extension
gets folded into the constant in SelectionDAG::getNode(). This means
that the instruction selection sees this:

(mul (sext i32), i64)
...which doesn't match the pattern. Sign-extension and 64-bit
multiply instructions are generated, which are slower than one 32-bit
multiply.

Add a pattern to match this and generate the correct instruction, for
both signed and unsigned multiplies.

Patch by Chris Diamand!

llvm-svn: 259800

Fix the lit bug that enabled this "feature" (empty triple is substring
of all possible target triples) and change the two outliers to use the
documented * syntax.

llvm-svn: 259799

This patch corresponds to review:
http://reviews.llvm.org/D16847

There are some files in glibc that use the output operand modifier even though
it was deprecated in GCC. This patch just adds support for it to prevent issues
with such files.

llvm-svn: 259798

llvm-svn: 259797

This patch adds support for consecutive (load/undef elements) 32-bit loads, followed by trailing undef/zero elements to be combined to a single MOVD load.

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

llvm-svn: 259796

This reverts commit r259790. tramp3d-v4 is still having problems.

llvm-svn: 259795

[X86][SSE] Added i686 target tests to make sure we are correctly loading consecutive entries as 64-bit integers

llvm-svn: 259794

Log message was wrong because an argument was missing.

llvm-svn: 259793

The FMA instruction was selected from AVX2 set instead of AVX-512

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

llvm-svn: 259792

This patch implements softening of long double type (ppcf128) on ppc32
architecture and enables operations for this type for soft float.

Patch by Strahinja Petrovic.

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

llvm-svn: 259791

This patch allows the mixing of scaled and unscaled load/stores to form
load/store pairs.

PR24465
http://reviews.llvm.org/D12116
Many thanks to Ahmed and Michael for fixes and code review.

This is a reapplication of r246769, which was reverted in r246782 due to a
test-suite failure.  I'm unable to reproduce the issue at this time.

llvm-svn: 259790

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

llvm-svn: 259789

[clang-tidy] More friendly warning in "google-runtime-references" when meeting an unnamed function parameter.

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 259787

llvm-svn: 259786

This allows code such as:

void multiple_types(char *Short, char *Float, char *Double) {
  for (long i = 0; i < 100; i++) {
    Short[i] = *(short *)&Short[2 * i];
    Float[i] = *(float *)&Float[4 * i];
    Double[i] = *(double *)&Double[8 * i];
  }
}

To model such code we use as canonical element type of the modeled array the
smallest element type of all original array accesses, if type allocation sizes
are multiples of each other. Otherwise, we use a newly created iN type, where N
is the gcd of the allocation size of the types used in the accesses to this
array. Accesses with types larger as the canonical element type are modeled as
multiple accesses with the smaller type.

For example the second load access is modeled as:

  { Stmt_bb2[i0] -> MemRef_Float[o0] : 4i0 <= o0 <= 3 + 4i0 }

To support code-generating these memory accesses, we introduce a new method
getAccessAddressFunction that assigns each statement instance a single memory
location, the address we load from/store to. Currently we obtain this address by
taking the lexmin of the access function. We may consider keeping track of the
memory location more explicitly in the future.

We currently do _not_ handle multi-dimensional arrays and also keep the
restriction of not supporting accesses where the offset expression is not a
multiple of the access element type size. This patch adds tests that ensure
we correctly invalidate a scop in case these accesses are found. Both types of
accesses can be handled using the very same model, but are left to be added in
the future.

We also move the initialization of the scop-context into the constructor to
ensure it is already available when invalidating the scop.

Finally, we add this as a new item to the 2.9 release notes

Reviewers: jdoerfert, Meinersbur

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

llvm-svn: 259784

llvm-svn: 259783

llvm-svn: 259782

This symbol is a "fake" symbol like "_gp_disp" and denotes
the GOT + 0x7FF0 value.

llvm-svn: 259781

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

llvm-svn: 259780

Symbol does not need an entry i the 'global' part of GOT if it cannot be
preempted. So canBePreempted fully satisfies us at least for now.

llvm-svn: 259779

If relocation against symbol requires GOT entry creation and this symbol
is defined in DSO, the GOT entry should be created in the 'global' part
of the GOT even if we link executable file. Also we do not need to create
a dynamic symbol table entry for global symbol corresponding to the
local GOT entry.

llvm-svn: 259778

Test has passed last 200 runs of the build bot.

llvm-svn: 259777

Codegen for array sections/array subscripts worked only for expressions with arrays as base. Patch fixes codegen for bases with pointer/reference types.

llvm-svn: 259776

previously, I have marked only one test as flaky, but now I noticed another test failing with the
same error. I am going to assume all of them are flaky.

llvm-svn: 259775

Summary:
gdb-remote tests are not able to use the same logging mechanisms as the rest of our tests, and
currently we get no host logs from them, even though the tests themselves have logging
capability. This commit changes that. When user specifies that he would like to log the
gdb-remote channel (--channel gdb-remote argument to dotest.py), we write detailed logs to the
<TEST_ID>-host.log file, just like we would in the case of regular tests. If this argument is not
specified, we only log the serious messages to stderr, which matches the existing behaviour.

Reviewers: tfiala, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 259774

Patch replaces the --refresh flag removed in r258800 with it's own command, 'language renderscript allocation refresh'.
Since there is no reason this functionality should be tied to another command as an option. 
The command itself simply re-JITs all our cached information about allocations.

llvm-svn: 259773