| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
r154362 was supposed to delete this bit, but obviously didn't.
rdar://11305594
llvm-svn: 155465
|
|
|
|
|
|
|
| |
Remove the v2f64 patterns because it does not match any vbroadcast
instruction.
llvm-svn: 155461
|
|
|
|
| |
llvm-svn: 155460
|
|
|
|
| |
llvm-svn: 155459
|
|
|
|
| |
llvm-svn: 155458
|
|
|
|
| |
llvm-svn: 155457
|
|
|
|
|
|
|
|
|
| |
current scheduling region.
The DAG builder is a convenient place to do it. Hopefully this is more
efficient than a separate traversal over the same region.
llvm-svn: 155456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineInstr sequence.
This uses the new target interface for tracking register pressure
using pressure sets to model overlapping register classes and
subregisters.
RegisterPressure results can be tracked incrementally or stored at
region boundaries. Global register pressure can be deduced from local
RegisterPressure results if desired.
This is an early, somewhat untested implementation. I'm working on
testing it within the context of a register pressure reducing
MachineScheduler.
llvm-svn: 155454
|
|
|
|
|
|
|
| |
immediate. We can't use it here because the shuffle code does not check that
the lower part of the word is identical to the upper part.
llvm-svn: 155440
|
|
|
|
|
|
| |
its vector
llvm-svn: 155439
|
|
|
|
|
|
|
|
|
| |
using the pattern (vbroadcast (i32load src)). In some cases, after we generate
this pattern new users are added to the load node, which prevent the selection
of the blend pattern. This commit provides fallback patterns which perform
in-vector broadcast (using in-vector vbroadcast in AVX2 and pshufd on AVX1).
llvm-svn: 155437
|
|
|
|
|
|
| |
compiled to run on a simulator.
llvm-svn: 155435
|
|
|
|
| |
llvm-svn: 155429
|
|
|
|
| |
llvm-svn: 155428
|
|
|
|
| |
llvm-svn: 155402
|
|
|
|
| |
llvm-svn: 155399
|
|
|
|
|
|
| |
the integer type is i8 (commonly used in graphics).
llvm-svn: 155397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on X86 Atom. Some of our tests failed because the tail merging part of
the BranchFolding pass was creating new basic blocks which did not
contain live-in information. When the anti-dependency code in the Post-RA
scheduler ran, it would sometimes rename the register containing
the function return value because the fact that the return value was
live-in to the subsequent block had been lost. To fix this, it is necessary
to run the RegisterScavenging code in the BranchFolding pass.
This patch makes sure that the register scavenging code is invoked
in the X86 subtarget only when post-RA scheduling is being done.
Post RA scheduling in the X86 subtarget is only done for Atom.
This patch adds a new function to the TargetRegisterClass to control
whether or not live-ins should be preserved during branch folding.
This is necessary in order for the anti-dependency optimizations done
during the PostRASchedulerList pass to work properly when doing
Post-RA scheduling for the X86 in general and for the Intel Atom in particular.
The patch adds and invokes the new function trackLivenessAfterRegAlloc()
instead of using the existing requiresRegisterScavenging().
It changes BranchFolding.cpp to call trackLivenessAfterRegAlloc() instead of
requiresRegisterScavenging(). It changes the all the targets that
implemented requiresRegisterScavenging() to also implement
trackLivenessAfterRegAlloc().
It adds an assertion in the Post RA scheduler to make sure that post RA
liveness information is available when it is needed.
It changes the X86 break-anti-dependencies test to use –mcpu=atom, in order
to avoid running into the added assertion.
Finally, this patch restores the use of anti-dependency checking
(which was turned off temporarily for the 3.1 release) for
Intel Atom in the Post RA scheduler.
Patch by Andy Zhang!
Thanks to Jakob and Anton for their reviews.
llvm-svn: 155395
|
|
|
|
| |
llvm-svn: 155393
|
|
|
|
| |
llvm-svn: 155392
|
|
|
|
| |
llvm-svn: 155387
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building LLVM on Linux with libc++ with CMake TIME_WITH_SYS_TIME is
undefined, and HAVE_SYS_TIME_H is defined. This ends up including
sys/time.h but not time.h. Unix/TimeValue.inc requires time.h for asctime_r
and localtime. libstdc++ seems to include time.h anyway, but libc++ does
not.
Fix this by always including time.h
llvm-svn: 155382
|
|
|
|
|
|
|
|
|
| |
find forward declarations in the context that the actual definition
will occur.
rdar://11291658
llvm-svn: 155380
|
|
|
|
|
|
| |
the stated developer policy.
llvm-svn: 155373
|
|
|
|
|
|
|
|
|
|
|
| |
test suite failures. The failures occur at each stage, and only get
worse, so I'm reverting all of them.
Please resubmit these patches, one at a time, after verifying that the
regression test suite passes. Never submit a patch without running the
regression test suite.
llvm-svn: 155372
|
|
|
|
| |
llvm-svn: 155367
|
|
|
|
| |
llvm-svn: 155366
|
|
|
|
| |
llvm-svn: 155365
|
|
|
|
| |
llvm-svn: 155364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Defer some shl transforms to DAGCombine.
The shl instruction is used to represent multiplication by a constant
power of two as well as bitwise left shifts. Some InstCombine
transformations would turn an shl instruction into a bit mask operation,
making it difficult for later analysis passes to recognize the
constsnt multiplication.
Disable those shl transformations, deferring them to DAGCombine time.
An 'shl X, C' instruction is now treated mostly the same was as 'mul X, C'.
These transformations are deferred:
(X >>? C) << C --> X & (-1 << C) (When X >> C has multiple uses)
(X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2) (When C2 > C1)
(X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2) (When C1 > C2)
The corresponding exact transformations are preserved, just like
div-exact + mul:
(X >>?,exact C) << C --> X
(X >>?,exact C1) << C2 --> X << (C2-C1)
(X >>?,exact C1) << C2 --> X >>?,exact (C1-C2)
The disabled transformations could also prevent the instruction selector
from recognizing rotate patterns in hash functions and cryptographic
primitives. I have a test case for that, but it is too fragile.
llvm-svn: 155362
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that the struct file_status on UNIX systems has two
members called st_dev and st_ino; those are also members of the
struct stat, and they are reserved identifiers which can also be
provided as #define (and this is the case for st_dev on Hurd).
The solution (attached) is to rename them, for example adding a
"fs_" prefix (= file status) to them.
Patch by Pino Toscano
llvm-svn: 155354
|
|
|
|
|
|
| |
the compiled source file.
llvm-svn: 155346
|
|
|
|
| |
llvm-svn: 155341
|
|
|
|
|
|
| |
just the switch. Saves a little bit of binary size.
llvm-svn: 155339
|
|
|
|
|
|
| |
128-bit versus 256-bit vectors. Be explicit about both sizes and use llvm_unreachable. Similar changes to getLegalSplat.
llvm-svn: 155337
|
|
|
|
| |
llvm-svn: 155336
|
|
|
|
|
|
| |
shuffle operand has a different type than the the shuffle result since it can never happen.
llvm-svn: 155333
|
|
|
|
| |
llvm-svn: 155332
|
|
|
|
| |
llvm-svn: 155331
|
|
|
|
| |
llvm-svn: 155330
|
|
|
|
|
|
| |
fixes an assert reading "1239123123123123" when the result is already 64-bit.
llvm-svn: 155329
|
|
|
|
| |
llvm-svn: 155328
|
|
|
|
|
|
|
| |
intructions are processed. So there's no need to look at them if they're used as
operands of other instructions.
llvm-svn: 155327
|
|
|
|
|
|
| |
an ConstantNode SDValue. getConstant was almost always called just before only to have the functions take it apart and build a new ConstantSDNode.
llvm-svn: 155325
|
|
|
|
| |
llvm-svn: 155321
|
|
|
|
|
|
| |
getUNDEF instead of requerying. Use &Mask[0] instead of Mask.data().
llvm-svn: 155320
|
|
|
|
| |
llvm-svn: 155319
|
|
|
|
|
|
| |
128-bit vectors to use either CONCAT_VECTORS or a helper function. CONCAT_VECTORS will itself be lowered to the same pattern as before. The helper function is needed for concats of BUILD_VECTORs since getNode(CONCAT_VECTORS) will just return a large BUILD_VECTOR and we may be trying to lower large BUILD_VECTORS when this occurs.
llvm-svn: 155318
|
|
|
|
|
|
| |
Found by valgrind.
llvm-svn: 155313
|
|
|
|
| |
llvm-svn: 155309
|