| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Each shadow only represents data flow that is restricted to its reaching
def. Propagating more than that could lead to spurious register liveness,
resulting in extra (incorrectly) block live-ins.
llvm-svn: 283143
|
|
|
|
|
|
|
|
|
|
| |
Normally, if conversion would add implicit uses for redefined registers,
e.g. R0<def> = add_if ..., R0<imp-use>. However, if only subregisters of
R0 are known to be live but not R0 itself, such implicit uses will not be
added, causing prior definitions of such subregisters and R0 itself to
become dead.
llvm-svn: 282626
|
|
|
|
|
|
| |
Added BoundaryNode check to isBestZeroLatency function.
llvm-svn: 281825
|
|
|
|
|
|
| |
to copy the new isAdd field in the tablegen data structure.
llvm-svn: 281447
|
|
|
|
|
|
|
| |
- Expand SELECT_CC and BR_CC for vector types.
- Implement TLI::isShuffleMaskLegal.
llvm-svn: 281397
|
|
|
|
| |
llvm-svn: 281339
|
|
|
|
|
|
|
| |
hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.
llvm-svn: 281306
|
|
|
|
|
|
|
|
|
|
|
| |
descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.
Patch by Sam Parker and Sjoerd Meijer.
Differential Revision: https://reviews.llvm.org/D23601
llvm-svn: 281304
|
|
|
|
| |
llvm-svn: 280987
|
|
|
|
|
|
| |
Recent change exposed this issue, breaking the Hexagon buildbots.
llvm-svn: 280973
|
|
|
|
|
|
|
|
| |
Shadow uses need to be analyzed together, since each individual shadow
will only have a partial reaching def. All shadows together may cover
a given register ref, while each individual shadow may not.
llvm-svn: 280855
|
|
|
|
| |
llvm-svn: 280717
|
|
|
|
|
|
| |
Reapply r280275, since MSVC accepts r280358.
llvm-svn: 280369
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r280268, it causes all MSVC 2013 to ICE. This
appears to have been fixed in a later MSVC 2013 update, because I cannot
reproduce it locally. That said, all upstream LLVM bots are broken right
now, so I am reverting.
Also reverts dependent change r280275, "[Hexagon] Deal with undefs when
extending live intervals".
llvm-svn: 280301
|
|
|
|
| |
llvm-svn: 280275
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24039
llvm-svn: 280244
|
|
|
|
|
|
| |
Patch by Pranav Bhandarkar.
llvm-svn: 279998
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug shows up with diamonds that share unpredicable, unanalyzable branches.
There's an included test case from Hexagon. What was happening was that we were
attempting to predicate the branch instruction despite the fact that it was
checked to be the same. Now for unanalyzable branches we skip over the branch
instructions when predicating the block.
Differential Revision: https://reviews.llvm.org/D23939
llvm-svn: 279985
|
|
|
|
|
|
|
|
| |
Add vector store print tracing option for hexagon vector instructions.
https://reviews.llvm.org/D23870
llvm-svn: 279739
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compute it
Rename AllVRegsAllocated to NoVRegs. This avoids the connotation of
running after register and simply describes that no vregs are used in
a machine function. With that we can simply compute the property and do
not need to dump/parse it in .mir files.
Differential Revision: http://reviews.llvm.org/D23850
llvm-svn: 279698
|
|
|
|
| |
llvm-svn: 279681
|
|
|
|
| |
llvm-svn: 279679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register allocator can split a live interval of a register into a set
of smaller intervals. After the allocation of registers is complete, the
rewriter will modify the IR to replace virtual registers with the corres-
ponding physical registers. At this stage, if a register corresponding
to a subregister of a virtual register is used, the rewriter will check
if that subregister is undefined, and if so, it will add the <undef> flag
to the machine operand. The function verifying liveness of the subregis-
ter would assume that it is undefined, unless any of the subranges of the
live interval proves otherwise.
The problem is that the live intervals created during splitting do not
have any subranges, even if the original parent interval did. This could
result in the <undef> flag placed on a register that is actually defined.
Differential Revision: http://reviews.llvm.org/D21189
llvm-svn: 279625
|
|
|
|
|
|
| |
Commit r279241 unintentionally reverted that ability.
llvm-svn: 279526
|
|
|
|
| |
llvm-svn: 279304
|
|
|
|
| |
llvm-svn: 279302
|
|
|
|
|
|
|
| |
- Recognize C2_cmpgtui, S2_tstbit_i, and S4_ntstbit_i.
- Avoid creating new-value instructions with both source operands equal.
llvm-svn: 279286
|
|
|
|
|
|
|
|
|
| |
Ensure that load locked and store conditional instructions are only
packetized with ALU32 instructions.
Patch by Ben Craig.
llvm-svn: 279272
|
|
|
|
|
|
| |
Patch by Jyotsna Verma.
llvm-svn: 279267
|
|
|
|
|
|
| |
Patch by Arnold Schwaighofer.
llvm-svn: 279251
|
|
|
|
|
|
| |
Patch by Brendon Cahoon.
llvm-svn: 279249
|
|
|
|
| |
llvm-svn: 279241
|
|
|
|
|
|
|
|
|
| |
Improved handling of fma, floating point min/max, additional load/store
instructions for floating point types.
Patch by Jyotsna Verma.
llvm-svn: 279239
|
|
|
|
| |
llvm-svn: 279067
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pipeliner was generating an invalid Phi name for an operand
in the epilog block, which caused an assert in the live variable
analysis pass. The fix is to the code that generates new Phis
in the epilog block. In this case, there is an existing Phi that
needs to be reused rather than creating a new Phi instruction.
Differential Revision: https://reviews.llvm.org/D23513
llvm-svn: 278805
|
|
|
|
| |
llvm-svn: 278796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a loop is not rotated (for example when optimizing for size), the latch is not the backedge. If we promote an expression to post-inc form, we not only increase register pressure and add a COPY for that IV expression but for all IVs!
Motivating testcase:
void f(float *a, float *b, float *c, int n) {
while (n-- > 0)
*c++ = *a++ + *b++;
}
It's imperative that the pointer increments be located in the latch block and not the header block; if not, we cannot use post-increment loads and stores and we have to keep both the post-inc and pre-inc values around until the end of the latch which bloats register usage.
llvm-svn: 278658
|
|
|
|
|
|
|
|
|
|
|
| |
LowerTargetConstantPool is not properly setting the TargetFlag to indicate
desired relocation. Coding error, the offset parameter was omitted, so the
TargetFlag was used as the offset, and the TargetFlag defaulted to zero.
This only affects -fpic compilation, and only those items created in a
Constant Pool, for example a vector of constants. Halide ran into this issue.
llvm-svn: 278614
|
|
|
|
| |
llvm-svn: 278416
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23207
llvm-svn: 278383
|
|
|
|
|
|
|
|
|
|
| |
From the point of view of register assignment, byval parameters are
ignored: a byval parameter is not going to be assigned to a register,
and it will not affect the assignments of subsequent parameters.
When matching registers with parameters in the bit tracker, make sure
to skip byval parameters before advancing the registers.
llvm-svn: 278375
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes it possible for tail-duplication and tail-merging to
be disjoint. By being less aggressive when merging during layout, there are no
overlapping cases between tail-duplication and tail-merging, provided the
thresholds are disjoint.
There is a remaining TODO to benchmark the succ_size() test for non-layout tail
merging.
llvm-svn: 278265
|
|
|
|
| |
llvm-svn: 278256
|
|
|
|
| |
llvm-svn: 278252
|
|
|
|
|
|
|
|
|
|
|
|
| |
Floating point instructions use general purpose registers, so the few
instructions that can put floating point immediates into registers are,
in fact, integer instruction. Use them explicitly instead of having
pseudo-instructions specifically for dealing with floating point values.
Simplify the constant loading instructions (from sdata) to have only two:
one for 32-bit values and one for 64-bit values: CONST32 and CONST64.
llvm-svn: 278244
|
|
|
|
| |
llvm-svn: 278040
|
|
|
|
| |
llvm-svn: 277740
|
|
|
|
| |
llvm-svn: 277727
|
|
|
|
| |
llvm-svn: 277626
|
|
|
|
|
|
|
|
| |
When the same base address is used to load two different data types, LSR
would assume a memory type of "void". This type is not sized and has no
alignment information. Checking for it causes a crash.
llvm-svn: 277601
|