[FastIsel][AArch64] Fix previous commit r214844 (Don't perform sign-/zero-extension for function arguments that have already been sign-/zero-extended.)

The original code would fail for unsupported value types like i1, i8, and i16.
This fix changes the code to only create a sub-register copy for i64 value types
and all other types (i1/i8/i16/i32) just use the source register without any
modifications.

getRegClassFor() is now guarded by the i64 value type check, that guarantees
that we always request a register for a valid value type.

llvm-svn: 214848

llvm-svn: 214847

This implements basic argument lowering for AArch64 in FastISel. It only
handles a small subset of the C calling convention. It supports simple
arguments that can be passed in GPR and FPR registers.

This should cover most of the trivial cases without falling back to
SelectionDAG.

This fixes <rdar://problem/17890986>.

llvm-svn: 214846

It broke compiling of most Benchmark and internal test, as clang got
clashed by segmentation fault or assertion.

llvm-svn: 214845

[FastISel][AArch64] Don't perform sign-/zero-extension for function arguments that have already been sign-/zero-extended.

llvm-svn: 214844

llvm-svn: 214843

shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lookups from
the MachineFunction easily.

Update the MIPS subtarget switching machinery to update this pointer
at the same time it runs.

llvm-svn: 214838

llvm-svn: 214837

llvm-svn: 214836

llvm-svn: 214835

dit pointed out on IRC that '__i = _VSTD::next(__i)' was a very long-winded way of writing '++__i'. Since I hate being thought of as long-winded (this checkin comment notwithstanding), I fixed it. No functionality change.

llvm-svn: 214834

Based on http://reviews.llvm.org/D4702 by Byoungyoung Lee!

llvm-svn: 214833

 sequence on AArch64

Re-commit of r214669 without changes to test cases
LLVM::CodeGen/AArch64/arm64-neon-mul-div.ll and
LLVM:: CodeGen/AArch64/dp-3source.ll
This resolves the reported compfails of the original commit.

llvm-svn: 214832

Suppression context might be used in multiple sanitizers working
simultaneously (e.g. LSan and UBSan) and not knowing about each other.

llvm-svn: 214831

llvm-svn: 214830

I forgot to add this with the changes for r214699.

llvm-svn: 214829

int __declspec(align(16)) foo; is a tentative definition but the storage
for that variable should not have CommonLinkage.

llvm-svn: 214828

llvm-svn: 214826

llvm-svn: 214825

/INCLUDE arguments passed as command line options are handled in the
same way as Unix -u. All option values are converted to an undefined
symbol and added to a dummy input file, so that the specified symbols
are resolved.

One tricky thing on Windows is that the option is also allowed to
appear in the object file's directive section. At the time when
it's being read, all (regular) command line options have already
been processed. We cannot add undefined atoms to the dummy file
anymore.

Previously, we added such /INCLUDE to a set that has already been
processed. As a result the options were ignored.

This patch fixes the issue. Now, /INCLUDE symbols in the directive
section are handled as real undefined symbol in the COFF file.
We create an undefined symbol for each /INCLUDE argument and add
it to the file being parsed.

llvm-svn: 214824

llvm-svn: 214816

Those registers are VFP/NEON and vector instructions should be used instead,
but old cores rely on those co-processors to enable VFP unwinding. This change
was prompted by the libc++abi's unwinding routine and is also present in many
legacy low-level bare-metal code that we ought to compile/assemble.

Fixing bug PR20025 and allowing PR20529 to proceed with a fix in libc++abi.

llvm-svn: 214802

My original LE implementation of the vsldoi instruction, with its
altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect
shufflevector operations in the LLVM IR.  Correct code is generated
because the back end handles the incorrect shufflevector in a
consistent manner.

This patch and a companion patch for LLVM correct this problem by
removing the fixup from altivec.h and the corresponding fixup from the
PowerPC back end.  Several test cases are also modified to reflect the
now-correct LLVM IR.

The vec_sums and vec_vsumsws interfaces in altivec.h are also fixed,
because they used vec_perm calls intended to be recognized as vsldoi
instructions.  These vec_perm calls are now replaced with code that
more clearly shows the intent of the transformation.

llvm-svn: 214801

My original LE implementation of the vsldoi instruction, with its
altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect
shufflevector operations in the LLVM IR.  Correct code is generated
because the back end handles the incorrect shufflevector in a
consistent manner.

This patch and a companion patch for Clang correct this problem by
removing the fixup from altivec.h and the corresponding fixup from the
PowerPC back end.  Several test cases are also modified to reflect the
now-correct LLVM IR.

llvm-svn: 214800

Duplicate the vararg tests for linux and add a tests which mixed
vararg arguments with darwin positional parameters.

Patch by: Janne Grunau <j@jannau.net>

llvm-svn: 214799

to use register units instead of registers.

reviewed by Jakob Stoklund Olesen.

llvm-svn: 214798

llvm-svn: 214797

llvm-svn: 214796

llvm-svn: 214795

clang/test/Sema/struct-packed-align.c: Add the case in MS mode that alignment doesn't affect packing.

Also, revert a couple of suppressions.
  r214298, "Suppress clang/test/Sema/struct-packed-align.c for targeting LLP64."
  r214301, "Suppress clang/test/Sema/struct-packed-align.c also on msvc for investigating."

llvm-svn: 214794

llvm-svn: 214793

It was always set to ".", which was duplicated in a few places.

llvm-svn: 214792

llvm-svn: 214791

Self assignment would lead to buckets of garbage, causing quadratic probing to hang.

llvm-svn: 214790

a mutex is acquired, but corresponding mutex is not provably not-held.  This
is based on the earlier negative requirements patch.

llvm-svn: 214789

This fix changes the parameters #r and #s that are passed to the UBFM/SBFM
instruction to get the zero/sign-extension for free.

The original problem was that the shift left would use the 32-bit shift even for
i8/i16 value types, which could leave the upper bits set with "garbage" values.

The arithmetic shift right on the other side would use the wrong MSB as sign-bit
to determine what bits to shift into the value.

This fixes <rdar://problem/17907720>.

llvm-svn: 214788

This comment was referring to the DiagnosticSeverity with RS_
prefixes, but they're actually DS_. I've also modernized the comment
style since I was changing it anyway.

llvm-svn: 214787

llvm-svn: 214786

This code is completely wrong. It is also dead, as if it were to *ever*
run, it would crash. Fortunately, after my work to the combiner, it is
at least *possible* to reach the code, and llvm-stress has found a test
case. Thanks to Patrick for reporting.

It would be really good if anyone who remembers how this code works and
what it was intended to do could add some more obvious test coverage
instead of my completely contrived and reduced test case. My test case
was so brittle I left a bread crumb comment in it to help the next
person to stumble on it and not know what it was actually testing for.

llvm-svn: 214785

llvm-svn: 214784