This is to match the naming of CD8_EltSize, CD8_Scale, etc.

No functional change.

llvm-svn: 213280

Passes the computed scaling factor in TSFlags rather than the old attributes.

Also removes the C++ version of computing the scaling factor (MemObjSize)
along with the asserts added by the previous patch.

No functional change.

llvm-svn: 213279

This does not actually move the logic yet but reimplements it in the Tablegen
language.  Then asserts that the new implementation results in the same value.

The next patch will remove the assert and the temporary use of the TSFlags and
remove the C++ implementation.

The formula requires a limited form of the logical left and right operators.
I implemented these with the bit-extract/insert operator (i.e. blah{bits}).

No functional change.

llvm-svn: 213278

Convert the operand to int if possible, i.e. if the value is properly
initialized.  (I suppose there is further room for improvement here to also
peform the shift if the uninitialized bits are shifted out.)

With this little change we can now compute the scaling factor for compressed
displacement with pure tablegen code in the X86 backend.  This is useful
because both the X86-disassembler-specific part of tablegen and the assembler
need this and TD is the natural sharing place.

The patch also adds the missing documentation for the shift and add operator.

llvm-svn: 213277

llvm-svn: 213276

The header contains an offset to the DWARF abbreviations for the CU.  The offset
must be section relative for COFF and absolute for others.  The non-assembly
code path for the DWARF header generation already had the correct emission for
the headers.  This corrects just the assembly path.  Due to the invalid
relocation, processing of the debug information would halt previously on the
first assembly input as the associated abbreviations would be out of range as
they would have the location increased by image base and the section offset.

This address PR20332.

llvm-svn: 213275

Windows itanium uses the GNUCOFF assmebly format, not ELF.

llvm-svn: 213274

Rather than use three EmitBytes, concatenate the string at compile time,
constructing a single StringRef and emitting the data in one shot.  This also
creates nicer assembly output.  NFC.

llvm-svn: 213273

  Offer the static functions to extract information out of an IslAst for node
  as members of IslAstInfo not as top level entities.

  + Refactor common code
  + Add isParallel and isReductionParallel
  + Rename IslAstUser to IslAstUserPayload to make it clear this is just a (or
    the) payload struct.

llvm-svn: 213272

Fix bug #20335 - memory leak when move-constructing a string with unequal allocator. Thanks to Thomas Koeppe for the report

llvm-svn: 213269

Also, add some tests to make sure we can handle surface/texture
queries on both Fermi and Kepler+.

llvm-svn: 213268

This is a follow-up to an IRC conversation with Richard last night; __assume
does not evaluate its argument, and so the argument should not contribute to
whether (__assume(e), constant) can be used where a constant is required.

llvm-svn: 213267

In MS-compatibility mode, we support the __assume builtin. The __assume builtin
does not evaluate its arguments, and we should issue a warning if __assume is
provided with an argument with side effects (because these effects will be
discarded).

This is similar in spirit to the warnings issued by other compilers (Intel
Diagnostic 2261, MS Compiler Warning C4557).

llvm-svn: 213266

Using a std::string instead of a StringRef because the Default case synthesizes a temporary std::string from a Twine. Assigning that into a StringRef causes the StringRef to refer to a temporary, and bad things happen.

This fixes a failing test case on Windows.

llvm-svn: 213265

llvm-svn: 213264

Format of __libc_malloc_dispatch has changed in Android L.
While we are moving towards a solution that does not depend on bionic
internals, here is something to support both K* and L releases.

llvm-svn: 213263

llvm-svn: 213262

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