Improving the name of the function parameter, which happens to solve two likely-less-than-useful MSVC warnings: warning C4258: 'I' : definition from the for loop is ignored; the definition from the enclosing scope is used.

llvm-svn: 214717

I ran into some test failures where common code changed vector division
by constant into a multiply-high operation (MULHU).  But these are not
implemented by the back-end, so we failed to recognize the insn.

Fixed by marking MULHU/MULHS as Expand for vector types.

llvm-svn: 214716

llvm-svn: 214715

This patch refactors code generation of vector comparisons.

This fixes a wrong code-gen bug for ISD::SETGE for floating-point types,
and improves generated code for vector comparisons in general.

Specifically, the patch moves all logic deciding how to implement vector
comparisons into getVCmpInst, which gets two extra boolean outputs
indicating to its caller whether its needs to swap the input operands
and/or negate the result of the comparison.  Apart from implementing
these two modifications as directed by getVCmpInst, there is no need
to ever implement vector comparisons in any other manner; in particular,
there is never a need to perform two separate comparisons (e.g. one for
equal and one for greater-than, as code used to do before this patch).

Reviewed by Bill Schmidt.

llvm-svn: 214714

llvm-svn: 214713

That reduces a number of `if` operators and prevent a combinatorics explosion
if/when more dynamic linker path variants added.

No functional changes.

llvm-svn: 214712

[asan] introduce __asan_poison_cxx_array_cookie. This is asan-rt part of PR19838 (Left OOB accesses on new[]-allocated arrays with array cookies are not detected). No tests yet. They will follow once I commit the clang part.

llvm-svn: 214711

Summary:
Adding __int128 support explicitly for x86_64 because currently it's on
only when pointer size >= 64 which is not the case for x32.

Test Plan: One of the tests using __int128 is updated

Reviewers: atanasyan, chandlerc

Subscribers: cfe-commits, rob.khasanov, zinovy.nis, dschuff

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

llvm-svn: 214710

Summary:
This patch also fixes an issue with the way the Mips assembler enables/disables architecture
features. Before this patch, the assembler never disabled feature bits. For example,
.set mips64
.set mips32r2

would result in the 'OR' of mips64 with mips32r2 feature bits which isn't right.
Unfortunately this isn't trivial to fix because there's not an easy way to clear
feature bits as the algorithm in MCSubtargetInfo (ToggleFeature) only clears the bits
that imply the feature being cleared and not the implied bits by the feature (there's a
better explanation to the code I added).

Patch by Matheus Almeida and updated by Toma Tabacu

Reviewers: vmedic, matheusalmeida, dsanders

Reviewed By: dsanders

Subscribers: tomatabacu, llvm-commits

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

llvm-svn: 214709

llvm-svn: 214708

use of PACKUS. It's cleaner that way.

I looked at implementing clever combine-based folding of PACKUS chains
into PSHUFB but it is quite hard and doesn't seem likely to be worth it.
The most annoying part would be detecting that the correct masking had
been done to use PACKUS-style instructions as a blend operation rather
than there being any saturating as is indicated by its name. We generate
really nice code for what few test cases I've come up with that aren't
completely contrived for this by just directly prefering PSHUFB and so
let's go with that strategy for now. =]

llvm-svn: 214707

Fix tests Clang::Sema/statements.c and Clang::SemaTemplate/instantiate-expr-1.cpp when AArch64 is the default target.

Commit r213935 added additional validation of register constants/size for AArch64 and because these tests which contain Intel assembler the new validation caused these tests to fail when the default target is changed to an AArch64 target.

llvm-svn: 214706

Haven't thought that I ever needed to do this, but in this case comparing the
index using pointer arithmetic turns out to be really ugly. It also generates
nasty sign-compare warnings on 32 bit targets.

llvm-svn: 214705

llvm-svn: 214704

llvm-svn: 214703

patterns of v16i8 shuffles.

This implements one of the more important FIXMEs for the SSE2 support in
the new shuffle lowering. We now generate the optimal shuffle sequence
for truncate-derived shuffles which show up essentially everywhere.

Unfortunately, this exposes a weakness in other parts of the shuffle
logic -- we can no longer form PSHUFB here. I'll add the necessary
support for that and other things in a subsequent commit.

llvm-svn: 214702

Summary:
This allows us to copy the parameter name from the definition (as a comment)
or insert /*unused*/ in both places.

Reviewers: alexfh, klimek

Subscribers: cfe-commits

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

llvm-svn: 214701

llvm-svn: 214700

CXXNameMangler::mangleUnqualifiedBlock believed that
MangleContext::getBlockId returned something that used Itanium-style
discriminator numbers.

Discriminator numbers start their numberign from 1 and the first
mangling that actually gets any sort of number mangled in is the second
discriminator.

However, Block IDs start from zero.  The logic for omitting the mangling
number did a ' > 1' instead of a ' > 0' comparison; this could
potentially cause mangling conflicts.

llvm-svn: 214699

A typedef of a typedef should have AlignIsRequired if *either* typedef
has an AlignAttr attached to it.

llvm-svn: 214698

This commit broke "make check" for several hours, so get it reverted.

llvm-svn: 214697

On Cygwin, getpagesize() returns 64k(AllocationGranularity).

In r214580, the size of X86GenInstrInfo.inc became 1499136.

FIXME: We should reorganize again getPageSize() on Win32.
MapFile allocates address along AllocationGranularity but view is mapped by physical page.

llvm-svn: 214681

I spent some time looking into a better or more principled way to handle
this. For example, by detecting arbitrary "unneeded" ORs... But really,
there wasn't any point. We just shouldn't build blatantly wrong code so
late in the pipeline rather than adding more stages and logic later on
to fix it. Avoiding this is just too simple.

llvm-svn: 214680

Fundamentally, there isn't a really portable way to test the constant
pool contents. Instead, pin this test to the bare-metal triple. This
also makes it a 64-bit triple which allows us to only match a single
constant pool rather than two. It can also just hard code the '.' prefix
as the format should be stable now that it has a fixed triple. Finally,
I've switched it to use CHECK-NEXT to be more precise in the instruction
sequence expected and to use variables rather than hard coding decisions
by the register allocator.

llvm-svn: 214679

poorly-worded warning for a case value that is not a possible value of the
switched-on expression.

llvm-svn: 214678

llvm-svn: 214677

llvm-svn: 214676

destroyed on shutdown regardless. Fixes a double-delete.

llvm-svn: 214675

llvm-svn: 214674

combines) until they are legal.

Doing it the old way could, when the stars align *just* right, cause
a node to get into the combine set prior to being legalized. Then, when
the same node showed up as an operand to another node later on (but not
so much later on that it had been deleted as dead) we would fail to add
it back to the worklist thinking it had already been combined. This
would in turn cause it to not be legalized. Fortunately, we can also
walk the operands looking for uncombined (and thus potentially
un-legalized) nodes late. It will still ensure that we walk all operands
of all nodes and send all of them through both the legalizer without
changes and the combiner at least once. (Which was the original goal of
this).

I have a test case for this bug, but it is terribly brittle. For
example, it will stop finding the bug the moment I enable the new
shuffle lowering. I don't yet have any test case that reliably exercises
this bug, and it isn't clear that it will be possible to craft one. It
is entirely possible that with the new shuffle lowering the two forms of
doing this are precisely equivalent. That doesn't mean we shouldn't take
the more conservative approach of insisting on things in the combined
set having survived the legalizer.

llvm-svn: 214673

GCC 4.8.2 points out the ambiguity in evaluation of the assertion condition:

lib/Target/X86/X86FloatingPoint.cpp:949:49: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
   assert(STReturns == 0 || isMask_32(STReturns) && N <= 2);

llvm-svn: 214672

GCC 4.8.2 objects to the tautological condition in the assert as the unsigned
value is guaranteed to be >= 0.  Simplify the assertion by dropping the
tautological condition.

llvm-svn: 214671

This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation.

This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon.

There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too.

llvm-svn: 214670

 sequence -  AArch64 target support

 This patch turns off madd/msub generation in the DAGCombiner and generates
 them in the MachineCombiner instead. It replaces the original code sequence
 with the combined sequence when it is beneficial to do so.

 When there is no machine model support it always generates the madd/msub
 instruction. This is true also when the objective is to optimize for code
 size: when the combined sequence is shorter is always chosen and does not
 get evaluated.

 When there is a machine model the combined instruction sequence
 is evaluated for critical path and resource length using machine
 trace metrics and the original code sequence is replaced when it is
 determined to be faster.

 rdar://16319955

llvm-svn: 214669

It's a bit more obvious what's going on if we use path::filename
rather than decrementing an iterator here.

llvm-svn: 214668

call Target::SetArchitecture instead of modifying a
reference to the target's architecture so that the
target logging can show that the arch has been changed.

llvm-svn: 214667

 sequence -  target independent framework

 When the DAGcombiner selects instruction sequences
 it could increase the critical path or resource len.

 For example, on arm64 there are multiply-accumulate instructions (madd,
 msub). If e.g. the equivalent  multiply-add sequence is not on the
 crictial path it makes sense to select it instead of  the combined,
 single accumulate instruction (madd/msub). The reason is that the
 conversion from add+mul to the madd could lengthen the critical path
 by the latency of the multiply.

 But the DAGCombiner would always combine and select the madd/msub
 instruction.

 This patch uses machine trace metrics to estimate critical path length
 and resource length of an original instruction sequence vs a combined
 instruction sequence and picks the faster code based on its estimates.

 This patch only commits the target independent framework that evaluates
 and selects code sequences. The machine instruction combiner is turned
 off for all targets and expected to evolve over time by gradually
 handling DAGCombiner pattern in the target specific code.

 This framework lays the groundwork for fixing
 rdar://16319955

llvm-svn: 214666

There is no needed for neither 1-dimensional nor higher dimensional arrays to
require positive offsets in the outermost array dimension.

We originally introduced this assumption with the support for delinearizing
multi-dimensional arrays.

llvm-svn: 214665

This makes EmitWindowsUnwindTables a virtual function and lowers the
implementation of the function to the X86WinCOFFStreamer.  This method is a
target specific operation.  This enables making the behaviour target dependent
by isolating it entirely to the target specific streamer.

llvm-svn: 214664

The frame information stored in this structure is driven by the requirements for
Windows NT unwinding rather than Windows 64 specifically.  As a result, this
type can be shared across multiple architectures (ARM, AXP, MIPS, PPC, SH).
Rename this class in preparation for adding support for supporting unwinding
information for Windows on ARM.

Take the opportunity to constify the members as everything except the
ChainedParent is read-only.  This required some adjustment to the label
handling.

llvm-svn: 214663