llvm-svn: 191301

llvm-svn: 191300

Most constant BUILD_VECTOR's are matched using ComplexPatterns which cover
bitcasted as well as normal vectors. However, it doesn't seem to be possible to
match ldi.[bhwd] in a type-agnostic manner (e.g. to support the widest range of
immediates, it should be possible to use ldi.b to load v2i64) using TableGen so
ldi.[bhwd] is matched using custom code in MipsSEISelDAGToDAG.cpp

This made the majority of the constant splat BUILD_VECTOR lowering redundant.
The only transformation remaining for constant splats is when an (up-to) 32-bit
constant splat is possible but the value does not fit into a 10-bit signed
integer. In this case, the BUILD_VECTOR is transformed into a bitcasted
BUILD_VECTOR so that fill.[bhw] can be used to splat the vector from a GPR32
register (which is initialized using the usual lui/addui sequence).

There are no additional tests since this is a re-implementation of previous
functionality. The change is intended to make it easier to implement some of
the upcoming instruction selection patches since they can rely on existing
support for BUILD_VECTOR's in the DAGCombiner.

compare_float.ll changed slightly because a BITCAST is no longer
introduced during legalization.

llvm-svn: 191299

This patch turns the -mv* hexagon options into aliases. We should really produce
errors for invalid versions in the driver, but this patch preserves the old
behavior for now.

llvm-svn: 191298

[mips][msa] Non-constant BUILD_VECTOR's should be expanded to INSERT_VECTOR_ELT instead of memory operations.

The resulting code is the same length, but doesnt cause memory traffic or latency.

llvm-svn: 191297

This covers the case where fmax_a can be used to implement ISD::FABS.

llvm-svn: 191296

No functional change.

llvm-svn: 191295

Since the error is always reported by one of the GCD workers, this will help avoid premature program termination with exit code 0.

llvm-svn: 191294

[mips][msa] Added support for matching andi, ori, nori, and xori from normal IR (i.e. not intrinsics)

llvm-svn: 191293

llvm-svn: 191292

llvm-svn: 191291

This required correcting the definition of the bsel and bseli intrinsics.

llvm-svn: 191290

This fixes PR16724.

llvm-svn: 191289

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