| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ADDs. MaxOffs is used as a threshold to limit the size of the offset. Tradeoffs
being: (1) If we can't materialize the large constant then we'll cause fast-isel
to bail. (2) Too large of an offset can't be directly encoded in the ADD
resulting in a MOV+ADD. Generally not a bad thing because otherwise we would
have had ADD+ADD, but on Thumb this turns into a MOVS+MOVT+ADD. Working on a fix
for that. (3) Conversely, too low of a threshold we'll miss opportunities to
coalesce ADDs.
rdar://10412592
llvm-svn: 144886
|
| |
|
|
|
|
| |
LOAD+EXTRACT_VECTOR_ELT into a single LOAD. Fixes PR10747/PR11393.
llvm-svn: 144863
|
| |
|
|
|
|
| |
target-independent selector or the target-specific selector.
llvm-svn: 144833
|
| |
|
|
|
|
|
|
|
| |
for a single miss and not all predecessor instructions that get selected by
the selection DAG instruction selector. This is still not exact (e.g., over
states misses when folded/dead instructions are present), but it is a step in
the right direction.
llvm-svn: 144832
|
| |
|
|
| |
llvm-svn: 144768
|
| |
|
|
|
|
| |
indexed loads/stores to the legalizer.
llvm-svn: 144767
|
| |
|
|
| |
llvm-svn: 144747
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
%arrayidx135 = getelementptr inbounds [4 x [4 x [4 x [4 x i32]]]]* %M0, i32 0, i64 0
%arrayidx136 = getelementptr inbounds [4 x [4 x [4 x i32]]]* %arrayidx135, i32 0, i64 %idxprom134
Prior to this commit, the GEP instruction that defines %arrayidx136 thought that
%arrayidx135 was a trivial kill. The GEP that defines %arrayidx135 doesn't
generate any code and thus %M0 gets folded into the second GEP. Thus, we need
to look through GEPs with all zero indices.
rdar://10443319
llvm-svn: 144730
|
| |
|
|
|
|
|
|
|
|
|
|
| |
registers is used
by later instructions.
Only done for DEC64m right now.
Fixes <rdar://problem/6172640>
llvm-svn: 144705
|
| |
|
|
| |
llvm-svn: 144648
|
| |
|
|
| |
llvm-svn: 144647
|
| |
|
|
| |
llvm-svn: 144634
|
| |
|
|
|
|
| |
runs. Fixes PR11029.
llvm-svn: 144438
|
| |
|
|
|
|
|
|
| |
maintain LegalizeDAG invariants, whenever we a node is replaced, we must attempt to delete it, and if it still
has uses after it is replaced (which can happen in rare cases due to CSE), we must revisit it.
llvm-svn: 144432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction lower optimization" in the pre-RA scheduler.
The optimization, rather the hack, was done before MI use-list was available.
Now we should be able to implement it in a better way, perhaps in the
two-address pass until a MI scheduler is available.
Now that the scheduler has to backtrack to handle call sequences. Adding
artificial scheduling constraints is just not safe. Furthermore, the hack
is not taking all the other scheduling decisions into consideration so it's just
as likely to pessimize code. So I view disabling this optimization goodness
regardless of PR11314.
llvm-svn: 144267
|
| |
|
|
|
|
| |
issue from PR11319.
llvm-svn: 144216
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
dragonegg self-host buildbot will recover (it is complaining about object
files differing between different build stages). Original commit message:
Add a hack to the scheduler to disable pseudo-two-address dependencies in
basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.
llvm-svn: 144188
|
| |
|
|
|
|
|
|
|
|
| |
basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.
llvm-svn: 144124
|
| |
|
|
|
|
|
|
| |
Add support for trimming constants to GetDemandedBits. This fixes some funky
constant generation that occurs when stores are expanded for targets that don't
support unaligned stores natively.
llvm-svn: 144102
|
| |
|
|
|
|
| |
When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses
llvm-svn: 144100
|
| |
|
|
|
|
|
|
| |
doesn't get confused by CSE later on. Fixes PR11318.
Re-commit of r144034, with an extra fix so that RemoveDeadNode doesn't blow up.
llvm-svn: 144055
|
| |
|
|
| |
llvm-svn: 144044
|
| |
|
|
|
|
| |
doesn't get confused by CSE later on. Fixes PR11318.
llvm-svn: 144034
|
| |
|
|
|
|
| |
and TargetLowering::BuildUDIV(). Fixes PR11283
llvm-svn: 143964
|
| |
|
|
|
|
|
| |
across calls, and only check for nested dependences on the special
call-sequence-resource register.
llvm-svn: 143660
|
| |
|
|
| |
llvm-svn: 143634
|
| |
|
|
|
|
|
|
| |
into the function. Reflect that here so that the array will be placed next to
the SP.
<rdar://problem/10128329>
llvm-svn: 143590
|
| |
|
|
|
|
| |
before the op legalizer and that the used type is legal.
llvm-svn: 143358
|
| |
|
|
| |
llvm-svn: 143308
|
| |
|
|
|
|
|
| |
If all of the inputs are zero/any_extended, create a new simple BV
which can be further optimized by other BV optimizations.
llvm-svn: 143297
|
| |
|
|
| |
llvm-svn: 143262
|
| |
|
|
|
|
|
|
|
| |
fixes: Use a separate register, instead of SP, as the
calling-convention resource, to avoid spurious conflicts with
actual uses of SP. Also, fix unscheduling of calling sequences,
which can be triggered by pseudo-two-address dependencies.
llvm-svn: 143206
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it fixes the dragonegg self-host (it looks like gcc is miscompiled).
Original commit messages:
Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.
Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.
Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.
Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.
This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.
Delete #if 0 code accidentally left in.
llvm-svn: 143188
|
| |
|
|
| |
llvm-svn: 143179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.
Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.
Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.
Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.
This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.
llvm-svn: 143177
|
| |
|
|
| |
llvm-svn: 143095
|
| |
|
|
| |
llvm-svn: 143080
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code. There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.
llvm-svn: 143026
|
| |
|
|
|
|
|
|
|
|
|
| |
This code makes different decisions when compiled into x87 instructions
because of different rounding behavior. That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).
This fixes PR11200.
llvm-svn: 143006
|
| |
|
|
| |
llvm-svn: 142959
|
| |
|
|
| |
llvm-svn: 142822
|
| |
|
|
| |
llvm-svn: 142821
|
| |
|
|
|
|
|
| |
physreg dependencies, and upcoming codegen changes will require proper
physreg dependence handling.
llvm-svn: 142816
|
| |
|
|
| |
llvm-svn: 142815
|
| |
|
|
|
|
| |
use of Sched::ILP instead, as Sched::Latency is going away.
llvm-svn: 142813
|
| |
|
|
|
|
| |
is going away.
llvm-svn: 142810
|
| |
|
|
|
|
|
|
| |
ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.
SetCC return type needs to be legalized via PromoteTargetBoolean.
llvm-svn: 142660
|
| |
|
|
|
|
|
|
| |
type.
2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.
llvm-svn: 142648
|
| |
|
|
|
|
| |
Clang.
llvm-svn: 142631
|
| |
|
|
|
|
| |
because they don't support physical register dependencies.
llvm-svn: 142620
|