llvm-svn: 213261

This commit is missing tests and there are a few points that need to be
addressed before a new user-facing option can be added:

  http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110198.html

This reverts commit r213112.

llvm-svn: 213260

llvm-svn: 213259

Before:
  aaaaaa = aaaaaaaaaaaa ? aaaaaaaaaa ? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
      : aaaaaaaaaaaaaaaaaaaaaa
      : aaaaaaaaaaaaaaaaaaaaaaaaaaaa;

After:
  aaaaaa = aaaaaaaaaaaa
               ? aaaaaaaaaa ? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                            : aaaaaaaaaaaaaaaaaaaaaa
               : aaaaaaaaaaaaaaaaaaaaaaaaaaaa;

llvm-svn: 213258

llvm-svn: 213257

This also uses TSFlags to mark machine instructions that are surface/texture
accesses, as well as the vector width for surface operations.  This is used
to simplify some of the switch statements that need to detect surface/texture
instructions

llvm-svn: 213256

Summary:
I'm planning on upstreaming some test cases for the inline assembly
usage in the Mozilla code base.  A lot of these test cases test the
recent fixes to this code.

Reviewers: rnk

Subscribers: cfe-commits

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

llvm-svn: 213255

ARMv8 has instructions to handle it, otherwise a libcall is needed.

llvm-svn: 213254

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

llvm-svn: 213253

Previously we asserted on this code. Currently compiler-rt doesn't
actually implement any of these new libcalls, but external help is
pretty much the only viable option for LLVM.

I've followed the much more generic "__truncST2" naming, as opposed to
the odd name for f32 -> f16 truncation. This can obviously be changed
later, or overridden by any targets that need to.

llvm-svn: 213252

x86 has no native ability to extend an f16 to f64, but the same result
is obtained if we expand it into two separate extensions: f16 -> f32
-> f64.

Unfortunately the same is not true for truncate, so that still results
in a compilation failure.

llvm-svn: 213251

Memory barrier __builtin_arm_[dmb, dsb, isb] intrinsics are required to
implement their corresponding ACLE and MSVC intrinsics.

This patch ports ARM dmb, dsb, isb intrinsic to AArch64.

Requires LLVM r213247.

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

llvm-svn: 213250

There should be no change in semantics at this stage.

llvm-svn: 213249

This makes the two intrinsics @llvm.convert.from.f16 and
@llvm.convert.to.f16 accept types other than simple "float". This is
only strictly needed for the truncate operation, since otherwise
double rounding occurs and there's no way to represent the strict IEEE
conversion. However, for symmetry we allow larger types in the extend
too.

During legalization, we can expand an "fp16_to_double" operation into
two extends for convenience, but abort when the truncate isn't legal. A new
libcall is probably needed here.

Even after this commit, various target tweaks are needed to actually use the
extended intrinsics. I've put these into separate commits for clarity, so there
are no actual tests of f64 conversion here.

llvm-svn: 213248

Memory barrier __builtin_arm_[dmb, dsb, isb] intrinsics are required to
implement their corresponding ACLE and MSVC intrinsics.

This patch ports ARM dmb, dsb, isb intrinsic to AArch64.

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

llvm-svn: 213247

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

llvm-svn: 213246

llvm-svn: 213245

Summary:
Generally speaking, mips-* vs mips64-* should not be used to make decisions
about the content or format of the ELF. This should be based on the ABI
and CPU in use. For example, `mips-linux-gnu-clang -mips64r2 -mabi=64`
should produce an ELF64 as should `mips64-linux-gnu-clang -mabi=64`.
Conversely, `mips64-linux-gnu-clang -mabi=n32` should produce an ELF32 as
should `mips-linux-gnu-clang -mips64r2 -mabi=n32`.

This patch fixes the e_flags but leaves the ELF32 vs ELF64 issue for now
since there is no apparent way to base this decision on the ABI and CPU.

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

llvm-svn: 213244

Summary:
The cpr1_size field describes the minimum register width to run the program
rather than the size of the registers on the target. MIPS32r6 was acting
as if -mfp64 has been given because it starts off with 64-bit FPU registers.

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

llvm-svn: 213243

Summary:
These options are not implemented yet but we act as if they are always
given.

The integrated assembler is driven by the clang driver so the e_flag test
cases should match the e_flags emitted by GCC+GAS rather than GAS
by itself.

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

llvm-svn: 213242

Summary:
With this patch (and a corresponding LLVM patch), assembling an empty file with
GCC and Clang -fintegrated-as produce near identical objects. The remaining
differences are:
* GCC/GAS produce objects have a .pdr section
* GCC/GAS produce objects have a .gnu.attributes section
Other differences are insignificant such as precise file offsets and the order
of strings in the string table.

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

llvm-svn: 213241

Triple.cpp still returns "arm64" as prefix for arm64 triple, causing Clang not
being able to select the correct GCCBuiltin IR.

This patch changes the value to correct prefix "aarch64". Regression test will
be added in the coming patch.

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

llvm-svn: 213240

Origin is meaningless for fully initialized values. Avoid
storing origin for function arguments that are known to
be always initialized (i.e. shadow is a compile-time null
constant).

This is not about correctness, but purely an optimization.
Seems to affect compilation time of blacklisted functions
significantly.

llvm-svn: 213239

llvm-svn: 213238

llvm-svn: 213237

llvm-svn: 213236

Experienced with Thunderbird build

Patch by Matti Niemenmaa

llvm-svn: 213235

llvm-svn: 213233

llvm-svn: 213232

Refactor code, no functionality change, test case moved from instcombine to instsimplify.

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

llvm-svn: 213231

llvm-svn: 213230

Skip calling GetUnderlyingObject in cases where it obviously
isn't from an alloca. This should only be a compile time improvement.

llvm-svn: 213229

llvm-svn: 213228

llvm-svn: 213227

Summary:
This patch adds the `<experimental/utility>` header as specified in the latest draft of the library fundamentals TS.

`<experimental/utility>` only contains `class erased_type`. 

This patch also updates the documentation to list the `erased_type` class as "initial implementation complete".

Test Plan:
Three test cases where added:

1. Test that `_LIBCPP_VERSION` is defined.
2. Test that `<utility>` has been included.
3. Test that `erased_type` is in the correct namespace and is constexpr default constructible.

Reviewers: mclow.lists

Reviewed By: mclow.lists

Subscribers: cfe-commits

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

llvm-svn: 213226

llvm-svn: 213225

 -- a constructor list initialization that unpacked an initializer list into
    constructor arguments and
 -- a list initialization that created as std::initializer_list and passed it
    as the first argument to a constructor

in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.

llvm-svn: 213224

llvm-svn: 213223

llvm-svn: 213222

This makes the opcode an opaque value (unsigned int) rather than the
enumeration.  This permits the use of target specific operands.

Split out the generic type into a MCWinEH header and add a supporting
MCWin64EH::Instruction to abstract out the selection of the opcode and
construction of the actual instruction.

llvm-svn: 213221