llvm-svn: 191288

llvm-svn: 191287

MIPS SelectionDAG changes:
* Added VCEQ, VCL[ET]_[SU] nodes to represent vector comparisons that produce a bitmask.

llvm-svn: 191286

llvm-svn: 191285

With this option, arbitrarily named module map files can be specified
to be loaded as required for headers in the respective (sub)directories.

This, together with the extern module declaration allows for specifying
module maps in a modular fashion without the need for files called
"module.map".

Among other things, this allows a directory to contain two modules that
are completely independent of one another.

Review: http://llvm-reviews.chandlerc.com/D1697.
llvm-svn: 191284

Review: http://llvm-reviews.chandlerc.com/D1546.

I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.

From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:

  use module-id

A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.

When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option

-fmodule-name=<module-id>.

The compiler at present only applies restrictions to the module directly
being built.

llvm-svn: 191283

this option to the assembler.

llvm-svn: 191282

Make sure that the code that handles the constant addresses is run for the
GEPs. This just refactors that code and then calls it for the GEPs that are
collected during the iteration.

<rdar://problem/12445434>

llvm-svn: 191281

llvm-svn: 191280

fix to come once I've tracked down the problem (which is pre-existing and not
related to the change which introduced this test).

llvm-svn: 191279

something, for variable templates.

llvm-svn: 191278

llvm-svn: 191277

llvm-svn: 191276

llvm/test/CodeGen/AArch64/neon-scalar-reduce-pairwise.ll: Use -mtriple here, or aach64-pecoff might be misassumed on win32 hosts.

llvm-svn: 191275

literal operators. Also, for now, allow the proposed C++1y "il", "i", and "if"
suffixes too. (Will revert the latter if LWG decides not to go ahead with that
change after all.)

llvm-svn: 191274

/PDBALTPATH:<path> is an option to embed a different path for the PDB file to
the binary than the actual PDB file location. Because we don't support PDB
file, we'll just ignore the option for now.

llvm-svn: 191273

llvm-svn: 191272

llvm-svn: 191271

llvm-svn: 191270

llvm-svn: 191269

llvm-svn: 191268

the CFA instructions when it was profiling an -fomit-frame-pointer function
and a "volatile" register was saved on the stack (e.g. an argument register).
<rdar://problem/15036546>

llvm-svn: 191267

llvm-svn: 191266

1. Fixed constructor of shared clause.
2. Some macros for clauses processing are replaced by private template methods.
3. Additional checks in sema analysis of OpenMP clauses.

llvm-svn: 191265

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.

llvm-svn: 191264

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.

llvm-svn: 191263

default-at-first-instruction UnwindPlan if we're at the beginning of a function and
the ABI can provide us with an UnwindPlan to get out of there before falling back
to the generic architectural default UnwindPlan (which usually assumes that the stack
has already been set up.)

Update the FuncUnwinders methods to gracefully handle the case where an assembly
profiler may not be available.

Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was
returning the wrong UnwindPlan to its caller.

llvm-svn: 191262

llvm-svn: 191261

Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.

This fixes PR16979.

llvm-svn: 191260

llvm-svn: 191259

PR17317.

llvm-svn: 191258

llvm-svn: 191257

llvm-svn: 191256

llvm-svn: 191255

llvm-svn: 191254

The order in which the comdat type unit sections appear in the output is
unspecified and may vary from machine to machine.

llvm-svn: 191253

The recursive nature of the address selection code can cause the stack to
explode if there is a long chain of GEPs. Convert the recursive bit into a
iterative method to avoid this.

<rdar://problem/12445434>

llvm-svn: 191252

gcc doesn't support "gcc -m sse" and this was not tested in clang and only
used for link argument on darwin, so this was very likely just a bug.

llvm-svn: 191251

This solves two problems:

1) MSBuild will not flag the build as unsuccessful just because we print
   an error in the output, since "error(clang):" doesn't seem to match
   the regex it's using.

2) It becomes more clear that the diagnostic is coming from clang as
   supposed to cl.exe.

Differential Revision: http://llvm-reviews.chandlerc.com/D1735

llvm-svn: 191250

This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.

Other than the options clang explicitly claims to know, this fixes pr9701.

llvm-svn: 191249