llvm-svn: 285711

Differential revision: https://reviews.llvm.org/D26171

llvm-svn: 285710

Fix rL285708

llvm-svn: 285709

Add the necessary definitions for RISC-V ELF files, including relocs. Also 
make necessary trivial change to ELFYaml, llvm-objdump, and llvm-readobj in 
order to work with RISC-V ELFs.

Differential Revision: https://reviews.llvm.org/D23557

llvm-svn: 285708

This is the first in a series of 10 initial patches that incrementally add an 
MC layer for RISC-V to LLVM. See 
<http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> for more 
discussion.

Differential Revision: https://reviews.llvm.org/D23557

llvm-svn: 285707

I think the former 'test50' had a typo making it functionally equivalent
to the former 'test49'; changed the predicate to provide more coverage.

llvm-svn: 285706

As it stands, the OperandMatchResultTy is only included in the generated
header if there is custom operand parsing. However, almost all backends
make use of MatchOperand_Success and friends from OperandMatchResultTy for
e.g. parseRegister. This is a pain when starting an AsmParser for a new
backend that doesn't yet have custom operand parsing. Move the enum to
MCTargetAsmParser.h.

This patch is a prerequisite for D23563

Differential Revision: https://reviews.llvm.org/D23496

llvm-svn: 285705

I wanted to implement this as a target independent expansion, however when
targets say they want to expand FP_TO_FP16 what they actually want is
the unsafe math expansion when possible and expansion to a libcall in all
other cases.

The only way to make this work as a target independent would be to add logic
to target's TargetLowering construction to mark theses nodes as Expand when
LegalizeDAG can use the unsafe expansion and mark them as LibCall when it
cannot.  I think this would be possible, but I think it would be too fragile
and complex as it would require targets to keep their expansion logic up
to date with the code in LegalizeDAG.

Reviewers: bogner, ab, t.p.northover, arsenm

Subscribers: wdng, llvm-commits, nhaehnle

Differential Revision: https://reviews.llvm.org/D25999

llvm-svn: 285704

Check Task Scheduling Constraint (TSC) on stealing of untied task.
This is needed because the untied task can produce tied children
those can break TSC if untied is not a descendant of current task.
This can cause live lock on complex tyasking tests
(e.g. kastors/strassen-task-dep).

Differential Revision: https://reviews.llvm.org/D26182

llvm-svn: 285703

Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we are
using FileSpecs to also represent remote files for which we cannot (easily)
retrieve modification time, it makes sense to make the decision to get the
modification time more explicit.

The new function returns a llvm::sys::TimePoint<>. To aid the transition
from TimeValue, I have added a constructor to it which enables implicit
conversion from a time_point.

Reviewers: zturner, clayborg

Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D25392

llvm-svn: 285702

purpose of the test was to have 2 different function attribute sets, but due
to a typo there was only one both with number #0.

llvm-svn: 285701

Summary:
This patch adds a command line option '-cl-ext' to control a set of
supported OpenCL extensions. Option accepts a comma-separated list
of extensions prefixed with '+' or '-'.

It can be used together with a target triple to override support for some
extensions:

  // spir target supports all extensions, but we want to disable fp64
  clang -cc1 -triple spir-unknown-unknown -cl-ext=-cl_khr_fp64

Special 'all' extension allows to enable or disable all possible
extensions:

  // only fp64 will be supported
  clang -cc1 -triple spir-unknown-unknown -cl-ext=-all,+cl_khr_fp64

Patch by asavonic (Andrew Savonichev).

Reviewers: joey, yaxunl

Subscribers: yaxunl, bader, Anastasia, cfe-commits

Differential Revision: https://reviews.llvm.org/D23712

llvm-svn: 285700

1. Delete identical tests
2. Rename tests to reflect actual functionality
3. Add comments
4. Add unsigned variants
5. Add vector variants with FIXME comments
6. Rename test file

llvm-svn: 285699

Summary:
One of the tests was flaky, because similarly to
https://reviews.llvm.org/D18697 (rL265391) - if there is a process running
which is with the same PID as in the core file, the minidump
core file debugging will fail, because we get some information from the
running process.
The fix is routing the ProcessInfo requests through the Process class
and overriding it in ProcessMinidump to return correct data.

Reviewers: labath

Subscribers: lldb-commits, beanz

Differential Revision: https://reviews.llvm.org/D26193

llvm-svn: 285698

These tests are of the form

try {
   action-that-may-throw
   assert(!exceptional-condition)
   assert(some-other-facts)
 } catch (relevant-exception) {
   assert(exceptional-condition)
 }

Under libcpp-no-exceptions there is still value in verifying
some-other-facts while avoiding the exceptional case. So for these tests
just conditionally check some-other-facts if exceptional-condition is
false. When exception are supported make sure that a true
exceptional-condition throws an exception

Differential Revision: https://reviews.llvm.org/D26136

llvm-svn: 285697

This patch introduces the combine:

(C1 shift (A add C2)) -> ((C1 shift C2) shift A)
iff A and C2 are both positive

If both A and C2 are know to be positive then we can safely split into 2 shifts, permitting the folding of the Inner shift.

Fix for the spec benchmark case mentioned by @nadav on PR15141 (assuming we can prove that the inputs as positive).

Differential Revision: https://reviews.llvm.org/D26000

llvm-svn: 285696

Skip tests that expect an exception to be thrown.

Differential Revision: https://reviews.llvm.org/D26184

llvm-svn: 285695

This patch corresponds to review https://reviews.llvm.org/D26092.
Committing on behalf of Tony Jiang.

llvm-svn: 285694

llvm-svn: 285693

Note: Test is per differential review, but the other changed code in the review was for an optimisation that din't quite work. Nevertheless, the test is valid for the unoptimised version of the fix.

Differential Review: https://reviews.llvm.org/D24658

llvm-svn: 285692

It was only used by build-id and that can easily compute it.

llvm-svn: 285691

[Reapplying r284580 and r285917 with fix and testing to ensure emitted jump tables for Thumb-1 have 4-byte alignment]

The TBB and TBH instructions in Thumb-2 allow jump tables to be compressed into sequences of bytes or shorts respectively. These instructions do not exist in Thumb-1, however it is possible to synthesize them out of a sequence of other instructions.

It turns out this sequence is so short that it's almost never a lose for performance and is ALWAYS a significant win for code size.

TBB example:
Before: lsls r0, r0, #2    After: add  r0, pc
        adr  r1, .LJTI0_0         ldrb r0, [r0, #6]
        ldr  r0, [r0, r1]         lsls r0, r0, #1
        mov  pc, r0               add  pc, r0
  => No change in prologue code size or dynamic instruction count. Jump table shrunk by a factor of 4.

The only case that can increase dynamic instruction count is the TBH case:

Before: lsls r0, r4, #2    After: lsls r4, r4, #1
        adr  r1, .LJTI0_0         add  r4, pc
        ldr  r0, [r0, r1]         ldrh r4, [r4, #6]
        mov  pc, r0               lsls r4, r4, #1
                                  add  pc, r4
  => 1 more instruction in prologue. Jump table shrunk by a factor of 2.

So there is an argument that this should be disabled when optimizing for performance (and a TBH needs to be generated). I'm not so sure about that in practice, because on small cores with Thumb-1 performance is often tied to code size. But I'm willing to turn it off when optimizing for performance if people want (also note that TBHs are fairly rare in practice!)

llvm-svn: 285690

Finds redundant variable and function declarations.

  extern int X;
  extern int X;  // <- redundant

Differential Revision: https://reviews.llvm.org/D24656

llvm-svn: 285689

Commit on behalf of: Coby Tayree

1.'v' constraint for (x86) non-avx arch imitates the already implemented 'x' constraint, i.e. allows XMM{0-15} & YMM{0-15} depending on the apparent arch & mode (32/64).
2.for the avx512 arch it allows [X,Y,Z]MM{0-31} (mode dependent)

This patch applies the needed changes to clang
LLVM patch: https://reviews.llvm.org/D25005

Differential Revision: https://reviews.llvm.org/D25005

llvm-svn: 285688

With this expressions alone track if they are absolute or not.

llvm-svn: 285687

llvm-svn: 285686

llvm-svn: 285685

Differential revision: https://reviews.llvm.org/D26077

llvm-svn: 285684

llvm-svn: 285683

Differential revision: https://reviews.llvm.org/D25627

llvm-svn: 285682

This patch corresponds to review https://reviews.llvm.org/D26095.
Committing on behalf of Tony Jiang.

llvm-svn: 285681

Differential revision: https://reviews.llvm.org/D26070

llvm-svn: 285680

This patch corresponds to review https://reviews.llvm.org/D26073.
Committing on behalf of Sean Fertile.

llvm-svn: 285679

Differential Revision: https://reviews.llvm.org/D26058

Patch by Victor Campos

llvm-svn: 285678

Skip these tests under libcpp-no-exceptions.

Differential Revision: https://reviews.llvm.org/D26141

llvm-svn: 285677

llvm-svn: 285676

If a response file included by construct @file itself includes a response file
and that file is specified by relative file name, current behavior is to resolve
the name relative to the current working directory. The change adds additional
flag to ExpandResponseFiles that may be used to resolve nested response file
names relative to including file. With the new mode a set of related response
files may be kept together and reference each other with short position
independent names.

Differential Revision: https://reviews.llvm.org/D24917

llvm-svn: 285675

Before:
  template <typename T>
      void F(T) &&
      = delete;

After:
  template <typename T>
  void F(T) && = delete;

llvm-svn: 285674

Before:
  void f() { f(float{1}, a *a); }

After:
  void f() { f(float{1}, a * a); }

llvm-svn: 285673

Before:
  aaaaa.as ();

After:
  aaaaa.as();

llvm-svn: 285672