| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
The other use really does only care about the SDNode (it checks the
opcode against a whitelist), but bitFieldPlacement can be misled if
the node produces multiple results.
Patch by Ismail Badawi.
llvm-svn: 274567
|
| |
|
|
|
|
|
|
|
|
| |
Because of the special immediate operand, the constant
bus is already used so SGPRs are never useful.
r263212 changed the name of the immediate operand, which
broke the verifier check for the restriction.
llvm-svn: 274564
|
| |
|
|
|
|
|
|
| |
integer instructions
Differential Revision: http://reviews.llvm.org/D21972
llvm-svn: 274551
|
| |
|
|
| |
llvm-svn: 274550
|
| |
|
|
| |
llvm-svn: 274545
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The important thing I was missing was ensuring newly added constants were kept in topological order. Repositioning the node is correct if the constant is newly added (so it has no topological ordering) but wrong if it already existed - positioning it next in the worklist would break the topological ordering.
Original commit message:
[Thumb] Select a BIC instead of AND if the immediate can be encoded more optimally negated
If an immediate is only used in an AND node, it is possible that the immediate can be more optimally materialized when negated. If this is the case, we can negate the immediate and use a BIC instead;
int i(int a) {
return a & 0xfffffeec;
}
Used to produce:
ldr r1, [CONSTPOOL]
ands r0, r1
CONSTPOOL: 0xfffffeec
And now produces:
movs r1, #255
adds r1, #20 ; Less costly immediate generation
bics r0, r1
llvm-svn: 274543
|
| |
|
|
| |
llvm-svn: 274537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D20443
It changes the legalization strategy for illegal vector types from integer
promotion to widening. This only applies for vectors with elements of width
that is a multiple of a byte since we have hardware support for vectors with
1, 2, 3, 8 and 16 byte elements.
Integer promotion for vectors is quite expensive on PPC due to the sequence
of breaking apart the vector, extending the elements and reconstituting the
vector. Two of these operations are expensive.
This patch causes between minor and major improvements in performance on most
benchmarks. There are very few benchmarks whose performance regresses. These
regressions can be handled in a subsequent patch with a DAG combine (similar
to how this patch handles int -> fp conversions of illegal vector types).
llvm-svn: 274535
|
| |
|
|
| |
llvm-svn: 274534
|
| |
|
|
| |
llvm-svn: 274533
|
| |
|
|
| |
llvm-svn: 274529
|
| |
|
|
|
|
|
|
|
| |
Normal archives do not have empty UID/GID fields. However, the Microsoft
Import library format is a customized archive (it just uses an alternate symbol
index format). When the import library is constructed by lib.exe, the UID and
GID fields are left empty. Do not abort on such an input.
llvm-svn: 274528
|
| |
|
|
| |
llvm-svn: 274520
|
| |
|
|
|
|
| |
This reverts commit r274510 - it made green dragon unhappy.
llvm-svn: 274512
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using DAG->getConstant instead of DAG->getTargetConstant. This meant that we could inadvertently increase the use count of a constant if stars aligned, which it did in this testcase. Increasing the use count of the constant could cause ISel to fall over (because DAGToDAG lowering assumed the constant had only one use!)
Original commit message:
[Thumb] Select a BIC instead of AND if the immediate can be encoded more optimally negated
If an immediate is only used in an AND node, it is possible that the immediate can be more optimally materialized when negated. If this is the case, we can negate the immediate and use a BIC instead;
int i(int a) {
return a & 0xfffffeec;
}
Used to produce:
ldr r1, [CONSTPOOL]
ands r0, r1
CONSTPOOL: 0xfffffeec
And now produces:
movs r1, #255
adds r1, #20 ; Less costly immediate generation
bics r0, r1
llvm-svn: 274510
|
| |
|
|
| |
llvm-svn: 274506
|
| |
|
|
| |
llvm-svn: 274503
|
| |
|
|
| |
llvm-svn: 274498
|
| |
|
|
|
|
| |
Added PSHUFD tests as well
llvm-svn: 274493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.
Also start using the attribute for memset, memcpy, and memmove intrinsics,
and remove their special-casing in BasicAliasAnalysis.
Reviewers: reames, joker.eph
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18714
llvm-svn: 274485
|
| |
|
|
|
|
|
|
|
|
| |
concatenation of the inputs more general purpose.
We can now handle concatenation of each source multiple times. The previous code just checked for each source to appear once in either order.
This also now handles an entire source vector sized piece having undef indices correctly. We now concat with UNDEF instead of using one of the sources. This is responsible for the test case change.
llvm-svn: 274483
|
| |
|
|
| |
llvm-svn: 274473
|
| |
|
|
|
|
|
|
| |
handle undef indices.
Undef indices can now be treated as zeros. Or if its undef ORed with zero, we will keep the undef.
llvm-svn: 274472
|
| |
|
|
|
|
| |
vectors doesn't handle undefs as well as it could. Fix coming in another commit.
llvm-svn: 274471
|
| |
|
|
|
|
|
|
|
|
| |
After the block placement, if a block ends with a conditional branch, but the
next block is not its successor. The conditional branch should be changed to
unconditional branch. This patch fixes PR28307, PR28297, PR28402.
Differential Revision: http://reviews.llvm.org/D21811
llvm-svn: 274470
|
| |
|
|
| |
llvm-svn: 274469
|
| |
|
|
| |
llvm-svn: 274468
|
| |
|
|
|
|
| |
comments
llvm-svn: 274466
|
| |
|
|
| |
llvm-svn: 274465
|
| |
|
|
| |
llvm-svn: 274464
|
| |
|
|
| |
llvm-svn: 274462
|
| |
|
|
| |
llvm-svn: 274461
|
| |
|
|
| |
llvm-svn: 274460
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for including the avx512 mask register information in the mask/maskz versions of shuffle instruction comments.
This initial version just adds support for MOVDDUP/MOVSHDUP/MOVSLDUP to reduce the mass of test regenerations, other shuffle instructions can be added in due course.
Differential Revision: http://reviews.llvm.org/D21953
llvm-svn: 274459
|
| |
|
|
| |
llvm-svn: 274458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This actually uncovered a surprisingly large chain of ultimately unused
TLI args.
From what I can gather, this argument is a remnant of when
isKnownNonNull would look at the TLI directly.
The current approach seems to be that InferFunctionAttrs runs early in
the pipeline and uses TLI to annotate the TLI-dependent non-null
information as return attributes.
This also removes the dependence of functionattrs on TLI altogether.
llvm-svn: 274455
|
| |
|
|
|
|
|
| |
It is implemented as a LoopAnalysis pass as
discussed and agreed upon.
llvm-svn: 274452
|
| |
|
|
| |
llvm-svn: 274450
|
| |
|
|
| |
llvm-svn: 274448
|
| |
|
|
| |
llvm-svn: 274444
|
| |
|
|
|
|
| |
generic IR
llvm-svn: 274443
|
| |
|
|
| |
llvm-svn: 274439
|
| |
|
|
| |
llvm-svn: 274436
|
| |
|
|
| |
llvm-svn: 274435
|
| |
|
|
|
|
| |
Its not worth trying to write out tests for all the avx512f builtins yet, just adding tests for lowering of generic IR as we transition to it (shuffles mainly right now).
llvm-svn: 274434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds one counter to the struct counter array for counting struct
array accesses.
Adds instrumentation to insert counter update for struct array
accesses.
Reviewers: aizatsky
Subscribers: llvm-commits, bruening, eugenis, kcc, zhaoqin, vitalybuka
Differential Revision: http://reviews.llvm.org/D21594
llvm-svn: 274420
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21945
llvm-svn: 274411
|
| |
|
|
|
|
| |
These are set on both the declaration record and the definition record.
llvm-svn: 274410
|
| |
|
|
|
|
|
| |
The main problem was counting comments on their own
line as instructions.
llvm-svn: 274405
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Given something like:
struct S {
int a;
struct { int b; };
};
We would fail to give 'b' offset 4. Instead, we would give it the
offset it has inside of it's struct.
llvm-svn: 274400
|