| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 84244
|
|
|
|
| |
llvm-svn: 84193
|
|
|
|
|
|
|
|
|
|
| |
header is just the entry block to the loop, and it needn't be at
the top of the loop in the code layout.
Remove the code that suppressed loop alignment for outer loops,
so that outer loops are aligned.
llvm-svn: 84158
|
|
|
|
|
|
| |
earlyclobber marker if the superreg def has it.
llvm-svn: 84153
|
|
|
|
| |
llvm-svn: 84152
|
|
|
|
| |
llvm-svn: 84138
|
|
|
|
| |
llvm-svn: 84134
|
|
|
|
| |
llvm-svn: 84133
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so get rid of eh.selector.i64 and rename eh.selector.i32 to eh.selector.
Likewise for eh.typeid.for. This aligns us with gcc, which always uses a
32 bit value for the selector on all platforms. My understanding is that
the register allocator used to assert if the selector intrinsic size didn't
match the pointer size, and this was the reason for introducing the two
variants. However my testing shows that this is no longer the case (I
fixed some bugs in selector lowering yesterday, and some more today in the
fastisel path; these might have caused the original problems).
llvm-svn: 84106
|
|
|
|
|
|
|
|
| |
to remat non-load instructions as loads, and the remat code now uses
the UnmodeledSideEffects flags, MachineMemOperands, and similar things
to decide which instructions are valid for rematerialization.
llvm-svn: 84060
|
|
|
|
| |
llvm-svn: 84059
|
|
|
|
|
|
| |
s/DebugLoc.InlinedLoc/DebugLoc.InlinedAtLoc/g
llvm-svn: 84054
|
|
|
|
|
|
|
|
|
|
|
|
| |
truncating an SDValue (depending on whether the target
type is bigger or smaller than the value's type); or zero
extending or truncating it. Use it in a few places (this
seems to be a popular operation, but I only modified cases
of it in SelectionDAGBuild). In particular, the eh_selector
lowering was doing this wrong due to a repeated rather than
inverted test, fixed with this change.
llvm-svn: 84027
|
|
|
|
| |
llvm-svn: 84011
|
|
|
|
| |
llvm-svn: 83950
|
|
|
|
| |
llvm-svn: 83922
|
|
|
|
| |
llvm-svn: 83921
|
|
|
|
|
|
|
|
|
| |
bootstrap of FSF-style PPC, so there is some
reason to believe the original bug (which was
never analyzed) has been fixed, probably by
82266.
llvm-svn: 83871
|
|
|
|
| |
llvm-svn: 83857
|
|
|
|
|
|
|
| |
compile time penalty on gnugo, the worst case in MultiSource, is down to
about 2.5% from 30%
llvm-svn: 83824
|
|
|
|
| |
llvm-svn: 83822
|
|
|
|
|
|
|
|
| |
into MachineInstrs. This is mostly just moving the code from
ScheduleDAGSDNodesEmit.cpp into a new class. This decouples MachineInstr
emitting from scheduling.
llvm-svn: 83699
|
|
|
|
|
|
|
| |
since it won't do any folding. This will help avoid some inconvenient
casting.
llvm-svn: 83698
|
|
|
|
| |
llvm-svn: 83695
|
|
|
|
|
|
| |
it isn't needed in the ScheduleDAGSDNodes schedulers.
llvm-svn: 83691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is trivially rematerializable and integrate it into
TargetInstrInfo::isTriviallyReMaterializable. This way, all places that
need to know whether an instruction is rematerializable will get the
same answer.
This enables the useful parts of the aggressive-remat option by
default -- using AliasAnalysis to determine whether a memory location
is invariant, and removes the questionable parts -- rematting operations
with virtual register inputs that may not be live everywhere.
llvm-svn: 83687
|
|
|
|
|
|
|
|
| |
alloca or llvm.dbg.declare location.
While recording beginning of a function, use scope info from the first location entry instead of just relying on first location entry itself.
llvm-svn: 83684
|
|
|
|
|
|
|
| |
TargetInstrDesc::isRematerializable flag, so it isn't necessary to do
this check in its callers.
llvm-svn: 83671
|
|
|
|
|
|
| |
information when unfolding memory references.
llvm-svn: 83656
|
|
|
|
|
|
| |
optimized away. Eventually DwarfChecker will clean this up during llvm verification stage.
llvm-svn: 83655
|
|
|
|
| |
llvm-svn: 83653
|
|
|
|
| |
llvm-svn: 83624
|
|
|
|
|
|
| |
licm'ed out of loop.
llvm-svn: 83622
|
|
|
|
| |
llvm-svn: 83608
|
|
|
|
| |
llvm-svn: 83589
|
|
|
|
| |
llvm-svn: 83571
|
|
|
|
|
|
| |
similar to getTargetExtractSubreg.
llvm-svn: 83564
|
|
|
|
|
|
| |
has arguments. Extra line number entries trip gdb in some cases.
llvm-svn: 83563
|
|
|
|
|
|
|
|
| |
to declare that they preserve other passes without needing to pull in
additional header file or library dependencies. Convert MachineFunctionPass
and CodeGenLICM to make use of this.
llvm-svn: 83555
|
|
|
|
| |
llvm-svn: 83521
|
|
|
|
|
|
| |
but are allocated by the scavenger. The re-use algorithm needs to watch for that.
llvm-svn: 83519
|
|
|
|
|
|
| |
what's up.
llvm-svn: 83501
|
|
|
|
| |
llvm-svn: 83500
|
|
|
|
| |
llvm-svn: 83496
|
|
|
|
| |
llvm-svn: 83483
|
|
|
|
| |
llvm-svn: 83481
|
|
|
|
|
|
|
|
| |
going to have the time
to finish it any time soon. If someone's interested it, they can resurrect it from SVN history.
llvm-svn: 83480
|
|
|
|
|
|
| |
teach it how to recognize invariant physical registers.
llvm-svn: 83476
|
|
|
|
|
|
|
|
|
| |
implementations with a new MachineInstr::isInvariantLoad, which uses
MachineMemOperands and is target-independent. This brings MachineLICM
and other functionality to targets which previously lacked an
isInvariantLoad implementation.
llvm-svn: 83475
|
|
|
|
| |
llvm-svn: 83474
|