| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 185072
|
|
|
|
| |
llvm-svn: 184933
|
|
|
|
|
|
| |
shift/xor/sub when it is possible. Fixed a bug in SDIV, where the const operand is not a splat constant vector.
llvm-svn: 184931
|
|
|
|
| |
llvm-svn: 184866
|
|
|
|
|
|
|
| |
This is a band-aid to fix the most severe regressions we're seeing from basing
spill decisions on block frequencies, until we have a better solution.
llvm-svn: 184835
|
|
|
|
| |
llvm-svn: 184792
|
|
|
|
| |
llvm-svn: 184788
|
|
|
|
|
|
| |
never modified. No functional change.
llvm-svn: 184781
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to write unit tests that are less susceptible
to minor code motion, particularly copy placement. block-placement.ll
covers this case with -pre-RA-sched=source which will soon be
default. One incorrectly named block is already fixed, but without
this fix, enabling new coalescing and scheduling would cause more
failures.
llvm-svn: 184680
|
|
|
|
|
|
| |
ULEB128/SLEB128 generation
llvm-svn: 184669
|
|
|
|
|
|
| |
and parameter packs
llvm-svn: 184643
|
|
|
|
| |
llvm-svn: 184642
|
|
|
|
|
|
|
|
|
| |
We have no targets on trunk that bundle before regalloc. However, we
have been advertising regalloc as bundle safe for use with out-of-tree
targets. We need to at least contain the parts of the code that are
still unsafe.
llvm-svn: 184620
|
|
|
|
|
|
|
|
|
|
|
|
| |
A FastISel optimization was causing us to emit no information for such
parameters & when they go missing we end up emitting a different
function type. By avoiding that shortcut we not only get types correct
(very important) but also location information (handy) - even if it's
only live at the start of a function & may be clobbered later.
Reviewed/discussion by Evan Cheng & Dan Gohman.
llvm-svn: 184604
|
|
|
|
|
|
|
| |
When (srl (anyextend x), c) is folded into (anyextend (srl x, c)), the
high bits are not cleared. Add 'and' to clear off them.
llvm-svn: 184575
|
|
|
|
| |
llvm-svn: 184574
|
|
|
|
| |
llvm-svn: 184573
|
|
|
|
|
|
|
|
|
|
| |
Live intervals for dead physregs may be created during coalescing. We
need to update these in the event that their instruction goes away.
crash.ll is the unit test that catches it when MI sched is enabled on
X86.
llvm-svn: 184572
|
|
|
|
|
|
| |
I want to add logic to handle more cases.
llvm-svn: 184571
|
|
|
|
| |
llvm-svn: 184570
|
|
|
|
| |
llvm-svn: 184569
|
|
|
|
|
|
|
| |
Always coalesce in forward order to propagate rematerialization.
I'm fixing this option so I can enable it by default soon.
llvm-svn: 184568
|
|
|
|
| |
llvm-svn: 184567
|
|
|
|
| |
llvm-svn: 184565
|
|
|
|
| |
llvm-svn: 184564
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function anyway
Fix up three tests - one that was relying on abbreviation number,
another relying on a location list in this case (& testing raw asm,
changed that to use dwarfdump on the debug_info now that that's where
the location is), and another which was added in r184368 - exposing a
bug in that fix that is exposed when we emit the location inline rather
than through a location list. Fix that bug while I'm here.
llvm-svn: 184387
|
|
|
|
| |
llvm-svn: 184376
|
|
|
|
| |
llvm-svn: 184373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.
Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).
llvm-svn: 184368
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184360
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184352
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184349
|
|
|
|
|
|
| |
already.
llvm-svn: 184346
|
|
|
|
|
|
|
|
|
|
|
|
| |
value is zero.
This allows optmizations to kick in more easily.
Fix some test cases so that they remain meaningful (i.e., not completely dead
coded) when optimizations apply.
<rdar://problem/14096009> superfluous multiply by high part of zero-extended
value.
llvm-svn: 184222
|
|
|
|
| |
llvm-svn: 184178
|
|
|
|
|
|
|
|
|
| |
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
llvm-svn: 184175
|
|
|
|
| |
llvm-svn: 184172
|
|
|
|
| |
llvm-svn: 184135
|
|
|
|
| |
llvm-svn: 184133
|
|
|
|
|
|
| |
A complex, expensive heuristic with little value in the current design.
llvm-svn: 184132
|
|
|
|
| |
llvm-svn: 184131
|
|
|
|
| |
llvm-svn: 184130
|
|
|
|
|
|
|
|
| |
This eliminates the MultiPressure scheduling "reason". It was
sensitive to queue order. We don't like being sensitive to queue
order.
llvm-svn: 184129
|
|
|
|
| |
llvm-svn: 184121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main advantages here are way better heuristics, taking into account not
just loop depth but also __builtin_expect and other static heuristics and will
eventually learn how to use profile info. Most of the work in this patch is
pushing the MachineBlockFrequencyInfo analysis into the right places.
This is good for a 5% speedup on zlib's deflate (x86_64), there were some very
unfortunate spilling decisions in its hottest loop in longest_match(). Other
benchmarks I tried were mostly neutral.
This changes register allocation in subtle ways, update the tests for it.
2012-02-20-MachineCPBug.ll was deleted as it's very fragile and the instruction
it looked for was gone already (but the FileCheck pattern picked up unrelated
stuff).
llvm-svn: 184105
|
|
|
|
|
|
|
|
|
|
| |
MachineInstrs
Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.
llvm-svn: 184067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.
Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.
llvm-svn: 184066
|
|
|
|
|
|
| |
offset when it's zero
llvm-svn: 184045
|
|
|
|
| |
llvm-svn: 184039
|
|
|
|
| |
llvm-svn: 184038
|