| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This actually was caught by existing tests but those tests were disabled
with an XFAIL because of PR20736. While working on fixing that,
I noticed the test failure, and tracked it down to this.
We even have a really nice Clang warning that would have caught this but
it isn't enabled in LLVM! =[ I may look at enabling it.
llvm-svn: 216391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GlobalDCE deletes global vars and updates their initializers to nullptr
while leaving underlying constants to be cleaned up later by its uses.
The clean up may never happen, fix this by forcing it every time it's
safe to destroy constants.
Final patch by Rafael Espindola
http://reviews.llvm.org/D4931
<rdar://problem/17523868>
llvm-svn: 216390
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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 tables are initialized when X86TargetLowering object is created.
llvm-svn: 216345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
| |
reduced testcase in that bug.
llvm-svn: 216307
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang's pgo.
This commit expands llvm-cov's functionality by adding support for a new code coverage
tool that uses LLVM's coverage mapping format and clang's instrumentation based profiling.
The gcov compatible tool can be invoked by supplying the 'gcov' command as the first argument,
or by modifying the tool's name to end with 'gcov'.
Differential Revision: http://reviews.llvm.org/D4445
llvm-svn: 216300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes PR20425.
During slice building, if all of the incoming values of a PHI node are the same, replace the PHI node with the common value. This simplification makes alloca's used by PHI nodes easier to promote.
Test Plan: Added three more tests in phi-and-select.ll
Reviewers: nlewycky, eliben, meheff, chandlerc
Reviewed By: chandlerc
Subscribers: zinovy.nis, hfinkel, baldrick, llvm-commits
Differential Revision: http://reviews.llvm.org/D4659
llvm-svn: 216299
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no need to do this if the user doesn't call va_start. In the
future, we're going to have thunks that forward these register
parameters with musttail calls, and they won't need these spills for
handling va_start.
Most of the test suite changes are adding va_start calls to existing
tests to keep things working.
llvm-svn: 216294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains the LLVM side of the fix of PR17239.
This bug that happens because the /link (clang-cl.exe argument) is
marked as "consume all remaining arguments". However, when inside a
response file, /link should only consume all remaining arguments inside
the response file where it is located, not the entire command line after
expansion.
My patch will change the semantics of the RemainingArgsClass kind to
always consume only until the end of the response file when the option
originally came from a response file. There are only two options in this
class: dash dash (--) and /link.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4899
Patch by Rafael Auler!
llvm-svn: 216280
|
|
|
|
| |
llvm-svn: 216279
|
|
|
|
| |
llvm-svn: 216278
|
|
|
|
|
|
|
|
|
| |
These pointers are really just offsets and they will always be
less than 16-bits. Using AssertZExt allows us to use computeKnownBits
to prove that these values are positive. We will use this information
in a later commit.
llvm-svn: 216277
|
|
|
|
|
|
|
| |
DS_1A uses a single offset encoding, so offset1 wasn't being
encoded.
llvm-svn: 216276
|
|
|
|
|
|
|
|
|
| |
instruction from ARMInstrInfo to ARMBaseInstrInfo.
That way, thumb mode can also benefit from the advanced copy optimization.
<rdar://problem/12702965>
llvm-svn: 216274
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider:
%add = add nuw i32 %a, -16777216
%and = and i32 %add, 255
Regardless of whether or not we demand the sign bit of %add, we cannot
replace -16777216 with 2130706432 without also removing 'nuw' from the
instruction.
llvm-svn: 216273
|
|
|
|
|
|
| |
We can preserve nsw during this transform if -C won't overflow.
llvm-svn: 216269
|
|
|
|
|
|
|
|
| |
calling convention if FP is 64-bit and +nooddspreg is used.
Differential Revision: http://reviews.llvm.org/D4981.diff
llvm-svn: 216262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider:
%add = add nsw i32 %a, -16777216
%and = and i32 %add, 255
Regardless of whether or not we demand the sign bit of %add, we cannot
replace -16777216 with 2130706432 without also removing 'nsw' from the
instruction.
This fixes PR20377.
llvm-svn: 216261
|