"svn" patch by Sedat Dilek plus trimming whitespace added in r229720.

llvm-svn: 230773

This removes a bit of duplicated code and more importantly, remembers the
labels so that they don't need to be looked up by name.

This in turn allows for any name to be used and avoids a crash if the name
we wanted was already taken.

llvm-svn: 230772

llvm-svn: 230771

The keys of the map are unique by pointer address, so there's no need
to use the llvm::less comparator. This allows us to use DenseMap
instead, which reduces tblgen time by 20% on my stress test.

llvm-svn: 230769

llvm-svn: 230766

Patch by Patrick Wildt.

llvm-svn: 230762

Differential Revision: http://reviews.llvm.org/D7934

llvm-svn: 230760

llvm-svn: 230759

This matches the assembly syntax.

llvm-svn: 230758

llvm-svn: 230757

Not passing mtriple for one of the tests caused a regression failure
on MIPS buildbot. The issue was introduced by r230651.

Differential Revision: http://reviews.llvm.org/D7938

llvm-svn: 230756

vectors. This lets us fix the rest of the v16 lowering problems when
pshufb is clearly better.

We might still be able to improve some of the lowerings by enabling the
other combine-based rewriting to fire for non-128-bit vectors, but this
at least should remove any regressions from using the fancy v16i16
lowering strategy.

llvm-svn: 230753

256-bit vectors as well as 128-bit vectors. Fixes some of the redundant
shuffles for v16i16.

llvm-svn: 230752

repeated 128-bit lane shuffles of wider vector types and use it to lower
256-bit v16i16 vector shuffles where applicable.

This should let us perfectly lowering the pattern of pshuflw and pshufhw
even for AVX2 256-bit patterns.

I've not added AVX-512 support, but it should be trivial for someone
working on that to wire up.

Note that currently this generates bad, long shuffle chains because we
don't combine 256-bit target shuffles. The subsequent patches will fix
that.

llvm-svn: 230751

by mirroring v8i16 test cases across both 128-bit lanes. This should
highlight problems where we aren't correctly using 128-bit shuffles to
implement things.

llvm-svn: 230750

Summary: Also fixes an infringement of the 80-column limit rule.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7910

llvm-svn: 230748

llvm-svn: 230747

llvm-svn: 230746

llvm-svn: 230745

llvm-svn: 230744

going back through the entire vector shuffle lowering.

This is an important step to being able to re-use this logic.

llvm-svn: 230743

Summary:
We identify the cases where the operand to an ADDE node is a constant
zero. In such cases, we can avoid generating an extra ADDu instruction
disguised as an identity move alias (ie. addu $r, $r, 0 --> move $r, $r).

Reviewers: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7906

llvm-svn: 230742

Currently, the ASan executables built with -O0 are unnecessarily slow.
The main reason is that ASan instrumentation pass inserts redundant
checks around promotable allocas. These allocas do not get instrumented
under -O1 because they get converted to virtual registered by mem2reg.
With this patch, ASan instrumentation pass will only instrument non
promotable allocas, giving us a speedup of 39% on a collection of
benchmarks with -O0. (There is no measurable speedup at -O1.)

llvm-svn: 230724

that is iterating over it

Inserting elements into a `DenseMap` invalidated iterators pointing
into the `DenseMap` instance.

Differential Revision: http://reviews.llvm.org/D7924

llvm-svn: 230719

AnalysisResult::getResultImpl reuses an iterator into a DenseMap after
inserting elements into it. This change adds code to recompute the
iterator before the second use.

llvm-svn: 230718

Summary:
This change causes us to actually save non-volatile registers in a Win64
ABI function that calls a System V ABI function, and vice-versa.

Reviewers: rnk

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7919

llvm-svn: 230714

llvm-svn: 230713

uses of TM->getSubtargetImpl and propagate to all calls.

This could be a debugging regression in places where we had a
TargetMachine and/or MachineFunction but don't have it as part
of the MachineInstr. Fixing this would require passing a
MachineFunction/Function down through the print operator, but
none of the existing uses in tree seem to do this.

llvm-svn: 230710

A small regression in r230411 was that we were basing the decision on
-fdata-sections.

llvm-svn: 230707

llvm-svn: 230705

llvm-svn: 230704

Function pointers were not correctly handled by the dumper, and
they would print as "* name".  They now print as
"int (__cdecl *name)(int arg1, int arg2)" as they should.

Also, doubles were being printed as floats.  This fixes that bug
as well, and adds tests for all builtin types. as well as a test
for function pointers.

llvm-svn: 230703

(Saving files works, who knew?)

llvm-svn: 230701

forwarding to the one that didn't take a context.

llvm-svn: 230700

a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.

llvm-svn: 230699

need this shortly to get a TargetRegisterInfo from the subtarget
for TargetLowering routines.

llvm-svn: 230698

blend as legal.

We made the same mistake in two different places. Whenever we are custom
lowering a v32i8 blend we need to check whether we are custom lowering
it only for constant conditions that can be shuffled, or whether we
actually have AVX2 and full dynamic blending support on bytes. Both are
fixed, with comments added to make it clear what is going on and a new
test case.

llvm-svn: 230695

Move SectionMap to its only user (emitDebugARanges) and
reorder to save a call to sort.

llvm-svn: 230693

Reverts commit r230686 with define modifications.

llvm-svn: 230692

dynamic blends.

This makes it much more clear what is going on. The case we're handling
is that of dynamic conditions, and we're bailing when the nature of the
vector types and subtarget preclude lowering the dynamic condition
vselect as an actual blend.

No functionality changed here, but this will make a subsequent bug-fix
to this code much more clear.

llvm-svn: 230690