The patch have completely broken COFF port and disabled many tests.
This also reverts r193302 (comment fix).

llvm-svn: 193362

llvm-svn: 193361

llvm-svn: 193360

class metadata for certain deployment targets. // rdar://14802916

llvm-svn: 193359

This may've been used at some point but the 'print' member function grew
an Indent parameter that entirely shadows this parameter.

llvm-svn: 193358

This commit changes the struct byval lowering for arm to use inline
checks for the subtarget instead of a class abstraction to represent
the differences. The class abstraction was judged to be too much
code for this task.

No intended functionality change.

llvm-svn: 193357

Patch by: Vincent Lejeune

llvm-svn: 193356

llvm-svn: 193355

This prevents us from silently accepting invalid instructions on (for example)
Cortex-M4 with just single-precision VFP support.

No tests for the extra Pat Requires because they're essentially assertions: the
affected code should have been lowered to libcalls before ISel.

rdar://problem/15302004

llvm-svn: 193354

Revert "Tooling/ReplacementsYaml.h: Prune Tooling's llvm::yaml::ScalarTraits<std::string> corresponding to LLVM r193344."

This reverts commit r193350, because it addressed an llvm API change that has been reverted.

llvm-svn: 193353

This fixes llvm.org/PR17682.

Without this patch, the following code leads to invalid reads/writes:
  DEBUG({
    return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
           aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
  });
  #if a
  #else
  #endif

Because of the #if-#else structure, the code is formatted and annotated
twice and becauce of the nested block, the annotated lines form a
hierarchical structure. This structure was not properly reset between
runs.

llvm-svn: 193352

llvm-svn: 193351

llvm-svn: 193350

Make sure we mark all loops (scalar and vector) when vectorizing,
so that we don't try to vectorize them anymore. Also, set unroll
to 1, since this is what we check for on early exit.

llvm-svn: 193349

llvm-svn: 193348

Also made move constructor handling safer.

llvm-svn: 193347

Tooling/ReplacementsYaml.h: Prune Tooling's llvm::yaml::ScalarTraits<std::string> corresponding to LLVM r193344.

llvm-svn: 193346

Specifically, if a braced list has at least one nested braced list,
format it either all on one line or in one column (i.e. one item per
line).

This seems in general to be an improvement as the structure of nested
braced lists can make a tightly packed outer braced list hard to read.

llvm-svn: 193345

llvm-svn: 193344

llvm-svn: 193343

The fused multiply instructions were added in VFPv4 but are still NEON
instructions, in particular they shouldn't be available on a Cortex-M4 not
matter how floaty it is.

llvm-svn: 193342

If an alias inherits directly from InstAlias then it doesn't get any default
"Requires" values, so llvm-mc will allow it even on architectures that don't
support the underlying instruction.

This tidies up the obvious VFP and NEON cases I found.

llvm-svn: 193340

Origin copying may destroy valid origin info. This is caused by
__msan_copy_origin widening the address range to the nearest 4-byte aligned
addresses both on the left and on the right. If the target buffer is
uninitialized and the source is fully initialized, this will result in
overriding valid origin of target buffer with stale (possibly 0) origin of the
source buffer.

With this change the widened origin is copied only if corresponding shadow
values are non zero.

llvm-svn: 193338

llvm-svn: 193335

llvm-svn: 193332

These arch arguments are used for embedded targets (obviously) which need a
different calling convention to iOS.

llvm-svn: 193328

The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1
code to make use of VFP instructions by switching back to ARM mode, they make
no sense for M-class processors which don't even have an ARM mode.

Given that justification, in practice this is a platform ABI decision so the
actual check is based on that rather than CPU features.

rdar://problem/15302004

llvm-svn: 193327

Significant changes:
- Also recognize these literals with missing "@" for robustness.
- Reorganize tests.

llvm-svn: 193325

llvm-svn: 193324

Without this, customers of the MCJIT were leaking memory like crazy.

It's not really clear what the *right* memory management is here, so I'm
not trying to add lots of tests or other logic, just trying to get us
back to a better baseline. I'll follow up on the original commit to
figure out the right path forward.

llvm-svn: 193323

POP instructions are aliased to the ARM LDM variants but have different syntax.
This caused two problems: we tried to access a non-existent operand to annotate
the '!', and the error message didn't make much sense.

With some vigorous hand-waving in the error message both problems can be
fixed.

llvm-svn: 193322

generated. See:

http://llvm.org/viewvc/llvm-project?view=revision&revision=193289

llvm-svn: 193321

llvm-svn: 193320

This GCC flag is useful when you want to control whether implicit
template instantiation occurs at the commandline level. Clang doesn't
currently support such controls, but technically *always* implicitly
instantiating (what Clang does, and what every other compiler still in
use does by default) is valid behavior even under
-fno-implicit-templates, it just may be slow and very wasteful. If
people really want this, we can try to implement it, but I don't have an
actual use.

This should help fix the build of libstdc++ with Clang, its build system
uses this flag.

llvm-svn: 193319

flag. We should probably wire at least some variants of this up to our
actual diagnostics engine, but I'm leaving that for someone else. This
fixes the builds of packages which hard code something here, at least
including libstdc++ itself.

llvm-svn: 193318

LLVM optimizers may widen accesses to packed structures that overflow the structure itself, but should be in bounds up to the alignment of the object

llvm-svn: 193317

When generating the IfTrue basic block during the F128CSEL pseudo-instruction
handling, the NZCV live-in for the newly created BB wasn't being added. This
caused a fault during MI-sched/live range calculation when the predecessor
for the fall-through BB didn't have a live-in for phys-reg as expected.

llvm-svn: 193316

llvm-svn: 193315

This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).

Two problems needed to be fixed which this patch exposed:

1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.

2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.

llvm-svn: 193314

llvm-svn: 193313