| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
into the same node, but with different non-memory operands, we need to replace
the memory operands after it's finished morphing.
llvm-svn: 106643
|
|
|
|
|
|
| |
DAGCombiner pass,"... it was causing both 'file' (with clang) and 176.gcc (with llvm-gcc) to be miscompiled.
llvm-svn: 106634
|
|
|
|
|
|
|
|
| |
atomic intrinsics, either because the use locking instructions for the
atomics, or because they perform the locking directly. Add support in the
DAG combiner to fold away the fences.
llvm-svn: 106630
|
|
|
|
| |
llvm-svn: 106627
|
|
|
|
|
|
|
|
|
|
| |
into a range where it"... it causes bzip2 to be miscompiled by Clang.
Conflicts:
lib/CodeGen/MachineSink.cpp
llvm-svn: 106614
|
|
|
|
|
|
|
|
|
| |
instructions.
This does not affect codegen much because SUBREG_TO_REG is only used by X86 and
X86 does not use the register scavenger, but it prevents verifier errors.
llvm-svn: 106583
|
|
|
|
|
|
|
| |
into a utility routine, teach it how to update MachineLoopInfo, and
make use of it in MachineLICM to split critical edges on demand.
llvm-svn: 106555
|
|
|
|
|
|
|
|
|
| |
Measurements show that it does not speed up coalescing, so there is no reason
the keep the added complexity around.
Also clean out some unused methods and static functions.
llvm-svn: 106548
|
|
|
|
| |
llvm-svn: 106542
|
|
|
|
|
|
| |
kill and dead flags will end up on.
llvm-svn: 106520
|
|
|
|
|
|
| |
getNamedMetadata().
llvm-svn: 106518
|
|
|
|
| |
llvm-svn: 106517
|
|
|
|
| |
llvm-svn: 106516
|
|
|
|
| |
llvm-svn: 106515
|
|
|
|
|
|
| |
in addition to the kill flags.
llvm-svn: 106512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
opportunities. For example, this lets it emit this:
movq (%rax), %rcx
addq %rdx, %rcx
instead of this:
movq %rdx, %rcx
addq (%rax), %rcx
in the case where %rdx has subsequent uses. It's the same number
of instructions, and usually the same encoding size on x86, but
it appears faster, and in general, it may allow better scheduling
for the load.
llvm-svn: 106493
|
|
|
|
|
|
| |
SmallVector, and other SmallVector simplifications.
llvm-svn: 106452
|
|
|
|
| |
llvm-svn: 106423
|
|
|
|
|
|
|
|
|
|
| |
Split the code for materializing a value out of
SelectionDAGBuilder::getValue into a helper function, so that it can
be used in other ways. Add a new getNonRegisterValue function which
uses it, for use in code which doesn't want a CopyFromReg even
when FuncMap.ValueMap already has an entry for it.
llvm-svn: 106422
|
|
|
|
| |
llvm-svn: 106415
|
|
|
|
|
|
|
| |
the LocalValueMap, to make it more flexible when fast-isel isn't
proceding straight top-down.
llvm-svn: 106414
|
|
|
|
| |
llvm-svn: 106383
|
|
|
|
|
|
| |
on calls and similar instructions.
llvm-svn: 106353
|
|
|
|
|
|
| |
the inserted INSERT_SUBREGs after us.
llvm-svn: 106345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This fixed a number of bugs in if-converter, tail merging, and post-allocation
scheduler. If-converter now runs branch folding / tail merging first to
maximize if-conversion opportunities.
- Also changed the t2IT instruction slightly. It now defines the ITSTATE
register which is read by instructions in the IT block.
- Added Thumb2 specific hazard recognizer to ensure the scheduler doesn't
change the instruction ordering in the IT block (since IT mask has been
finalized). It also ensures no other instructions can be scheduled between
instructions in the IT block.
This is not yet enabled.
llvm-svn: 106344
|
|
|
|
| |
llvm-svn: 106342
|
|
|
|
|
|
|
|
|
| |
instructions, but it doesn't really understand live ranges, so the first
INSERT_SUBREG uses an implicitly defined register.
Fix it in LiveVariableAnalysis by adding the <undef> flag.
llvm-svn: 106333
|
|
|
|
| |
llvm-svn: 106330
|
|
|
|
| |
llvm-svn: 106324
|
|
|
|
|
|
| |
dbg_value's which resulted in non-duplicated instructions being deleted. rdar://8104384.
llvm-svn: 106323
|
|
|
|
|
|
|
|
|
|
| |
entries used by llvm-gcc. *_[U]MIN and such can be added later if needed.
This enables the front ends to simplify handling of the atomic intrinsics by
removing the target-specific decision about which targets can handle the
intrinsics.
llvm-svn: 106321
|
|
|
|
|
|
| |
std::vector.
llvm-svn: 106298
|
|
|
|
|
|
|
| |
MachineRegisterInfo doesn't have to confusingly allocate an extra
entry.
llvm-svn: 106296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so when IfConverter::CopyAndPredicateBlock checks to see if it should ignore
an instruction because it is a branch, it should not check if the branch is
predicated.
This case (when IgnoreBr is true) is only relevant from IfConvertTriangle,
where new branches are inserted after the block has been copied and predicated.
If the original branch is not removed, we end up with multiple conditional
branches (possibly conflicting) at the end of the block. Aside from any
immediate errors resulting from that, this confuses the AnalyzeBranch functions
so that the branches are not analyzable. That in turn causes the IfConverter to
think that the "Simple" pattern can be applied, and things go downhill fast
because the "Simple" pattern does _not_ apply if the block can fall through.
This is pretty fragile. If there are other degenerate cases where AnalyzeBranch
fails, but where the block may still fall through, the IfConverter should not
perform its "Simple" if-conversion. But, I don't know how to do that with the
current AnalyzeBranch interface, so for now, the best thing seems to be to
avoid creating branches that AnalyzeBranch cannot handle.
Evan, please review!
llvm-svn: 106291
|
|
|
|
| |
llvm-svn: 106287
|
|
|
|
| |
llvm-svn: 106286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
switch from this:
if (TimePassesIsEnabled) {
NamedRegionTimer T(Name, GroupName);
do_something();
} else {
do_something(); // duplicate the code, this time without a timer!
}
to this:
{
NamedRegionTimer T(Name, GroupName, TimePassesIsEnabled);
do_something();
}
llvm-svn: 106285
|
|
|
|
|
|
| |
the old one.
llvm-svn: 106284
|
|
|
|
|
|
|
| |
Don't replace the old DbgInfo with a new one when clear() on the
old one is sufficient.
llvm-svn: 106283
|
|
|
|
|
|
| |
SDNode *, since it doesn't care about the ResNo value.
llvm-svn: 106282
|
|
|
|
| |
llvm-svn: 106279
|
|
|
|
| |
llvm-svn: 106278
|
|
|
|
|
|
| |
which is faster, simpler, and less surprising.
llvm-svn: 106263
|
|
|
|
| |
llvm-svn: 106256
|
|
|
|
|
|
|
|
|
|
|
|
| |
addresses a longstanding deficiency noted in many FIXMEs scattered
across all the targets.
This effectively moves the problem up one level, replacing eleven
FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path
through FastISel where we actually supply a DebugLoc, fixing Radar
7421831.
llvm-svn: 106243
|
|
|
|
|
|
| |
for correctness' sake, it should be there.
llvm-svn: 106229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the moment. The implementation of the libcall will follow.
Currently, the llvm-gcc knows when the intrinsics can be correctly handled by
the back end and only generates them in those cases, issuing libcalls directly
otherwise. That's too much coupling. The intrinsics should always be
generated and the back end decide how to handle them, be it with a libcall,
inline code, or whatever. This patch is a step in that direction.
rdar://8097623
llvm-svn: 106227
|
|
|
|
|
|
| |
sets the legalize action to Expand.
llvm-svn: 106203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LiveVariableAnalysis was a bit picky about a register only being redefined once,
but that really isn't necessary.
Here is an example of chained INSERT_SUBREGs that we can handle now:
68 %reg1040<def> = INSERT_SUBREG %reg1040, %reg1028<kill>, 14
register: %reg1040 +[70,134:0)
76 %reg1040<def> = INSERT_SUBREG %reg1040, %reg1029<kill>, 13
register: %reg1040 replace range with [70,78:1) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,134:0) 0@78-(134) 1@70-(78)
84 %reg1040<def> = INSERT_SUBREG %reg1040, %reg1030<kill>, 12
register: %reg1040 replace range with [78,86:2) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,86:2)[86,134:0) 0@86-(134) 1@70-(78) 2@78-(86)
92 %reg1040<def> = INSERT_SUBREG %reg1040, %reg1031<kill>, 11
register: %reg1040 replace range with [86,94:3) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,86:2)[86,94:3)[94,134:0) 0@94-(134) 1@70-(78) 2@78-(86) 3@86-(94)
rdar://problem/8096390
llvm-svn: 106152
|
|
|
|
| |
llvm-svn: 106126
|