Added fp register clobbering during calls.
Added AsmPrinter support for "fmask", a bitmask that indicates where on the
stack the fp callee saved registers are.
Fixed the stack frame layout for Mips, now the callee saved regs
are in the right stack location (a little documentation about how this
stack frame must look like is present in MipsRegisterInfo.cpp).
This was done using the method MipsRegisterInfo::adjustMipsStackFrame
To be more clear, these are examples of what is solves :
1) FP and RA are also callee saved, and despite they aren't in CSI they
must be saved before the fp callee saved registers.
2) The ABI requires that local varibles are allocated before the callee
saved register area, the opposite behavior from the default allocation.
3) CPU and FPU saved register area must be aligned independent of each
other.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54403 91177308-0d34-0410-b5e6-96231b3b80d8
- Add a basic machine-level dead block eliminator.
These two have to go together, since many other parts of the code generator are unable to handle the unreachable blocks otherwise created.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54333 91177308-0d34-0410-b5e6-96231b3b80d8
version uses a new algorithm for evaluating the binomial coefficients
which is significantly more efficient for AddRecs of more than 2 terms
(see the comments in the code for details on how the algorithm works).
It also fixes some bugs: it removes the arbitrary length restriction for
AddRecs, it fixes the silent generation of incorrect code for AddRecs
which require a wide calculation width, and it fixes an issue where we
were incorrectly truncating the iteration count too far when evaluating
an AddRec expression narrower than the induction variable.
There are still a few related issues I know of: I think there's
still an issue with the SCEVExpander expansion of AddRec in terms of
the width of the induction variable used. The hack to avoid generating
too-wide integers shouldn't be necessary; instead, the callers should be
considering the cost of the expansion before expanding it (in addition
to not expanding too-wide integers, we might not want to expand
expressions that are really expensive, especially when optimizing for
size; calculating an length-17 32-bit AddRec currently generates about 250
instructions of straight-line code on X86). Also, for long 32-bit
AddRecs on X86, CodeGen really sucks at scheduling the code. I'm planning on
filing follow-up PRs for these issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54332 91177308-0d34-0410-b5e6-96231b3b80d8
aren't used anyway, they also used to broke compiling when fastcc was specified for a
function, but not anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54316 91177308-0d34-0410-b5e6-96231b3b80d8
Added hi,lo registers to be used,def implicitly. This provides better handle of
instructions which use hi/lo.
Fixes a small BranchAnalysis bug
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54274 91177308-0d34-0410-b5e6-96231b3b80d8
switches use the binary search algorithm) for
environments that don't support it. PPC64 JIT
is such an environment; turn the flag on for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54248 91177308-0d34-0410-b5e6-96231b3b80d8
subreg form on x86-64, to avoid the problem with x86-32
having GPRs that don't have 8-bit subregs.
Also, change several 16-bit instructions to use
equivalent 32-bit instructions. These have a smaller
encoding and avoid partial-register updates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54223 91177308-0d34-0410-b5e6-96231b3b80d8
to different address spaces. This alters the naming scheme for those
intrinsics, e.g., atomic.load.add.i32 => atomic.load.add.i32.p0i32
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54195 91177308-0d34-0410-b5e6-96231b3b80d8
time applying to the implicit comparison in smin expressions. The
correct way to transform an inequality into the opposite
inequality, either signed or unsigned, is with a not expression.
I looked through the SCEV code, and I don't think there are any more
occurrences of this issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54194 91177308-0d34-0410-b5e6-96231b3b80d8
SGT exit condition. Essentially, the correct way to flip an inequality
in 2's complement is the not operator, not the negation operator.
That said, the difference only affects cases involving INT_MIN.
Also, enhance the pre-test search logic to be a bit smarter about
inequalities flipped with a not operator, so it can eliminate the smax
from the iteration count for simple loops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54184 91177308-0d34-0410-b5e6-96231b3b80d8
the operand's interval that share the relevant value number, not just the range that immediately precedes the PHI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54174 91177308-0d34-0410-b5e6-96231b3b80d8
to be marked invalid regardless of whether it is
a debug, an exception handling or (hopefully) a
GC label.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54172 91177308-0d34-0410-b5e6-96231b3b80d8
partially unroll a loop when fully unrolling would not fit under the threshold.
Patch by Mikael Lepistö.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54160 91177308-0d34-0410-b5e6-96231b3b80d8
that says "unconditional loads from this argument are safe", we now keep track
of the safety per set of indices from which loads happen. This prevents
ArgPromotion from promoting loads that aren't really valid. As an added effect,
this will now disregard the the type of the indices passed to a GEP, so
"load GEP %A, i32 1" and "load GEP %A, i64 1" will result in a single argument,
not two.
This fixes PR2598, for which a testcase has been added as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54159 91177308-0d34-0410-b5e6-96231b3b80d8
which is represented in codegen as an 'and' operation. This matches them
with movz instructions, instead of leaving them to be matched by and
instructions with an immediate field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54147 91177308-0d34-0410-b5e6-96231b3b80d8
a new ilist_node class, and remove them. Unlike alist_node,
ilist_node doesn't attempt to manage storage itself, so it avoids
the associated problems, including being opaque in gdb.
Adjust the Recycler class so that it doesn't depend on alist_node.
Also, change it to use explicit Size and Align parameters, allowing
it to work when the largest-sized node doesn't have the greatest
alignment requirement.
Change MachineInstr's MachineMemOperand list from a pool-backed
alist to a std::list for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54146 91177308-0d34-0410-b5e6-96231b3b80d8
circumstances we could end up remapping a dependee to the same instruction
that we're trying to remove. Handle this properly by just falling back to
a conservative solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54132 91177308-0d34-0410-b5e6-96231b3b80d8
parallel its analogue, Value::value_use_iterator. The operator* method
now returns the user, rather than the use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54127 91177308-0d34-0410-b5e6-96231b3b80d8
is to have StrongPHIElimination use its knowledge of the PHIs before they're erased to update the intervals appropriate. This is
both simpler and more accurate than the alternative, which was having LIA figure it out when it renumbered things, plus it's just
the right thing to do!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54077 91177308-0d34-0410-b5e6-96231b3b80d8
by the PHI needs to be extended to the beginning of its basic block, and the intervals that were inputs need to be trimmed to the end
of their basic blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54070 91177308-0d34-0410-b5e6-96231b3b80d8
This is tricky business, and will probably take a few more iterations to get
the last kinks out of it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54043 91177308-0d34-0410-b5e6-96231b3b80d8
mmx needs its own fancy shuffle logic based on unpack; for now we get correct but awful code.
Also commit Mon Ping's VSETCC patch
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54039 91177308-0d34-0410-b5e6-96231b3b80d8
regressions, such as PR2595. Also, there is a significant code-quality
issue in SPEC 464.h264ref and a few others.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54014 91177308-0d34-0410-b5e6-96231b3b80d8
