A MachineLoopRange contains the intervals of slot indexes covered by the blocks
in a loop. This representation of the loop blocks is more efficient to compare
against interfering registers during register coalescing.
llvm-svn: 121917
(performing the addition in a wider type and explicitly checking for overflow), and
fold them down to intrinsics. This currently only supports signed-addition, but could
be generalized if someone works out the magic constant formulas for other operations.
Fixes <rdar://problem/8558713>.
llvm-svn: 121905
and "save_volatiles" correctly. This completes the custom calling convention
functionality changes for the MBlaze backend that were started in 121888.
llvm-svn: 121891
While LLVM's main design is that analysis code shouldn't
go out of its way to understand code which hasn't been
InstCombined, analysis utility routines like this can
find themselves being called in the middle of transform
passes when instcombine hasn't had a chance to run.
llvm-svn: 121886
* mergeIn now uses constant folding for constants that are provably not-equal.
* sink some sanity checks from the get*() methods into the mark*() methods, to ensure that we never have a constant/notconstant ConstantInt
* some textual cleanups, whitespace changes, removing "else" after return, that sort of thing.
llvm-svn: 121877
Bypass loops have the current live range live through, but contain no uses or
defs. Splitting around a bypass loop can free registers for other uses inside
the loop by spilling the split range.
llvm-svn: 121871
Some quad-register intrinsics with lane operands only take a double-register
operand for the vector containing the lane. The valid range of lane numbers
is then half as big as you would expect from the quad-register type.
Note: This currently has no effect because those intrinsics are now handled
entirely in the header file using __builtin_shufflevector, which does its own
range checking, but I want to use this for generating tests.
llvm-svn: 121867
it to be replaced by undef rather than not replaced at all, the idea being that
this may reduce the amount of work done by whoever called InstructionSimplify.
llvm-svn: 121860
When it sees a promising select it now tries to figure out whether the condition of the select is known in any of the predecessors and if so it maps the operands appropriately.
llvm-svn: 121859
With this we don't need the EffectiveSize field anymore. Without that field
LayoutFragment only updates offsets and we don't need to invalidate the
current fragment when it is relaxed (only the ones following it).
This is also a very small improvement in the accuracy of the layout info as
we now use the after relaxation size immediately.
llvm-svn: 121857
