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