llvm-svn: 216389

Patterns for lowering libm calls to VCVT{A,N,P,M} are also included.
Phabricator Revision: http://reviews.llvm.org/D5033

llvm-svn: 216388

Extended avx512_icmp_packed multiclass by masking versions.
Added avx512_icmp_packed_rmb multiclass for embedded broadcast versions.
Added corresponding _vl multiclasses.
Added encoding tests for CPCMP{EQ|GT}* instructions.
Add more fields for X86VectorVTInfo.
Added AVX512VLVectorVTInfo that include X86VectorVTInfo for 512/256/128-bit versions

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

llvm-svn: 216383

cmpAPFloat has been renamed to cmpAPFloats (multiple form).

llvm-svn: 216376

cmpAPInt has been renamed to cmpAPInts (multiple form).

llvm-svn: 216375

cmpType has been renamed to cmpTypes (multiple form).

llvm-svn: 216374

cmpGEP has been renamed to cmpGEPs (multiple form).

llvm-svn: 216373

This patch adds support to recognize division by uniform power of 2 and modifies the cost table to vectorize division by uniform power of 2 whenever possible.
Updates Cost model for Loop and SLP Vectorizer.The cost table is currently only updated for X86 backend.
Thanks to Hal, Andrea, Sanjay for the review. (http://reviews.llvm.org/D4971)

llvm-svn: 216371

This makes runOnMachineFunction vastly more readable.

llvm-svn: 216368

No functionality change.

llvm-svn: 216367

llvm-svn: 216366

llvm-svn: 216365

llvm-svn: 216364

Also make members that are never accessed outside the class
private.

llvm-svn: 216363

NFC.

llvm-svn: 216362

llvm-svn: 216361

llvm-svn: 216360

llvm-svn: 216359

llvm-svn: 216358

llvm-svn: 216357

This parameter is never null.

llvm-svn: 216356

llvm-svn: 216355

This was added in r134994, to fix a memory leak;
three days later, r135248 switched
ContainedTys from being new-allocated to being allocated
via BumpPtrAllocator, and the earlier fix was never
reverted.

The destructor doesn't seem to ever actually be called
on Types anyway, so it's harmless, but if it were,
this'd be an invalid pointer.

This reverts r134994.

llvm-svn: 216354

llvm-svn: 216351

llvm-svn: 216350

This does nothing but remove the Record from the map, and
then re-add it, without actually changing it in between.

The Record's Name used to be changed before re-adding it
when the code was first committed in r137232, but the
name-changing lines were removed in r142510, and since
then this code seems to do nothing.

This was also the only caller of removeClass or removeDef,
so now RecordKeeper owns its Records unconditionally,
and could be unique_ptr-ified.

llvm-svn: 216349

llvm-svn: 216348

The switch statement would never fire due to the preceding break statement. Also, the switch statement has a default label with no case labels. Simplified the code, and allow it to execute.

llvm-svn: 216346

The tables are initialized when X86TargetLowering object is created.

llvm-svn: 216345

llvm-svn: 216344

CFE, with -03, would turn:
bool f(unsigned x) {
  bool a = x & 1;
  bool b = x & 2;
  return a | b;
}

into:
  %1 = lshr i32 %x, 1
  %2 = or i32 %1, %x
  %3 = and i32 %2, 1
  %4 = icmp ne i32 %3, 0

This sort of thing exposes a nasty pathology in GCC, ICC and LLVM.

Instead, we would rather want:
  %1 = and i32 %x, 3
  %2 = icmp ne i32 %1, 0

Things get a bit more interesting in the following case:
  %1 = lshr i32 %x, %y
  %2 = or i32 %1, %x
  %3 = and i32 %2, 1
  %4 = icmp ne i32 %3, 0

Replacing it with the following sequence is better:
  %1 = shl nuw i32 1, %y
  %2 = or i32 %1, 1
  %3 = and i32 %2, %x
  %4 = icmp ne i32 %3, 0

This sequence is preferable because %1 doesn't involve %x and could
potentially be hoisted out of loops if it is invariant; only perform
this transform in the non-constant case if we know we won't increase
register pressure.

llvm-svn: 216343

Adds code generation support for dcbtst (data cache prefetch for write) and
icbt (instruction cache prefetch for read - Book E cores only).

We still end up with a 'cannot select' error for the non-supported prefetch
intrinsic forms. This will be fixed in a later commit.

Fixes PR20692.

llvm-svn: 216339

Based on the STL class of the same name, it guards a mutex
while also allowing it to be unlocked conditionally before
destruction.

This eliminates the last naked usages of mutexes in LLVM and
clang.

It also uncovered and fixed a bug in callExternalFunction()
when compiled without USE_LIBFFI, where the mutex would never
be unlocked if the end of the function was reached.

llvm-svn: 216338

Use lock/unlock() convention instead of acquire/release().

llvm-svn: 216336

Only one function remains a bit too complicated
for a simple mutex guard. No functionality change.

llvm-svn: 216335

This test was testing nothing, as only -Werror was ever
being added to the compiler flags.

You can see the final nitty-gritty compiler invocation in
CMakeFiles/CMakeOutput.log (for successful tests) and
CMakeFiles/CMakeError.log (for failed tests).

Before:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang   -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default  -DC_WCOMMENT_ALLOWS_LINE_WRAP  -Werror   -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o   -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c

After:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang   -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default  -DC_WCOMMENT_ALLOWS_LINE_WRAP  -Werror -Wcomment   -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o   -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c

llvm-svn: 216328

clang has only been smart enough not to trigger -Wnon-virtual-dtor
warnings on final classes since r208449 (in clang 3.5). Building
with older versions is extremely noisy, so disable the warning
on those compilers.

llvm-svn: 216327

This reverts commit r215862 due to nightly failures.  Will work on getting a
reduced test case, but I wanted to get our bots green in the meantime.

llvm-svn: 216325

This reverts commit r215863.

llvm-svn: 216324

these DAG combines.

The DAG auto-CSE thing is truly terrible. Due to it, when RAUW-ing
a node with its operand, you can cause its uses to CSE to itself, which
then causes their uses to become your uses which causes them to be
picked up by the RAUW. For nodes that are determined to be "no-ops",
this is "fine". But if the RAUW is one of several steps to enact
a transformation, this causes the DAG to really silently eat an discard
nodes that you would never expect. It took days for me to actually
pinpoint a test case triggering this and a really frustrating amount of
time to even comprehend the bug because I never even thought about the
ability of RAUW to iteratively consume nodes due to CSE-ing them into
itself.

To fix this, we have to build up a brand-new chain of operations any
time we are combining across (potentially) intervening nodes. But once
the logic is added to do this, another issue surfaces: CombineTo eagerly
deletes the one node combined, *but no others*. This is... really
frustrating. If deleting it makes its operands become dead, those
operand nodes often won't go onto the worklist in the
order you would want -- they're already on it and not near the top. That
means things higher on the worklist will get combined prior to these
dead nodes being GCed out of the worklist, and if the chain is long, the
immediate users won't be enough to re-detect where the root of the chain
is that became single-use again after deleting the dead nodes. The
better way to do this is to never immediately delete nodes, and instead
to just enqueue them so we can recursively delete them. The
combined-from node is typically not on the worklist anyways by virtue of
having been popped off.... But that in turn breaks other tests that
*require* CombineTo to delete unused nodes. :: sigh ::

Fortunately, there is a better way. This whole routine should have been
returning the replacement rather than using CombineTo which is quite
hacky. Switch to that, and all the pieces fall together.

I suspect the same kind of miscompile is possible in the half-shuffle
folding code, and potentially the recursive folding code. I'll be
switching those over to a pattern more like this one for safety's sake
even though I don't immediately have any test cases for them. Note that
the only way I got a test case for this instance was with *heavily* DAG
combined 256-bit shuffle sequences generated by my fuzzer. ;]

llvm-svn: 216319