The new instructions have explicit register output operands and use table-gen
patterns instead of C++ code to do instruction selection.
Mips16's instructions are unaffected by this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178403 91177308-0d34-0410-b5e6-96231b3b80d8
there were inline br .+4 instructions. Soon everything can enjoy the
full instruction scheduling experience.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175718 91177308-0d34-0410-b5e6-96231b3b80d8
SltCCRxRy16, SltiCCRxImmX16, SltiuCCRxImmX16, SltuCCRxRy16
$T8 shows up as register $24 when emitted from C++ code so we had
to change some tests that were already there for this functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175593 91177308-0d34-0410-b5e6-96231b3b80d8
at this time, llvm is generating a different but equivalent pattern
that would lead to this instruction. I am trying to think of a way
to get it to generate this. If I can't, I may just remove the pseudo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175419 91177308-0d34-0410-b5e6-96231b3b80d8
This expansion will be moved to expandISelPseudos as soon as I can figure
out how to do that. There are other instructions which use this
ExpandFEXT_T8I816_ins and as soon as I have finished expanding them all,
I will delete the macro asm string text so it has no way to be used
in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175413 91177308-0d34-0410-b5e6-96231b3b80d8
up so that we can apply the direct object emitter patch. This patch
should be a nop right now and it's test is to not break what is already
there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175126 91177308-0d34-0410-b5e6-96231b3b80d8
if the offset fits in 11 bits. This makes use of the fact that the abi
requires sp to be 8 byte aligned so the actual offset can fit in 8
bits. It will be shifted left and sign extended before being actually used.
The assembler or direct object emitter will shift right the 11 bit
signed field by 3 bits. We don't need to deal with that here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175073 91177308-0d34-0410-b5e6-96231b3b80d8
same so we put in the comment field an indicator when we think we are
emitting the 16 bit version. For the direct object emitter, the difference is
important as well as for other passes which need an accurate count of
program size. There will be other similar putbacks to this for various
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174747 91177308-0d34-0410-b5e6-96231b3b80d8
but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.
Formatting fixes. Mostly long lines and
blank spaces at end of lines.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172882 91177308-0d34-0410-b5e6-96231b3b80d8
these patches are tested a lot by test-suite but
make check tests are forthcoming once the next
few patches that complete this are committed.
with the next few patches the pass rate for mips16 is
near 100%
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170656 91177308-0d34-0410-b5e6-96231b3b80d8
Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.
Sorry for the noise. =]
I've also switch the comment block to use a \brief tag and not duplicate
the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168996 91177308-0d34-0410-b5e6-96231b3b80d8
We will make them delay slot forms if there is something that can be
placed in the delay slot during a separate pass. Mips16 extended instructions
cannot be placed in delay slots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166990 91177308-0d34-0410-b5e6-96231b3b80d8
Previously mips16 was sharing the pattern addr which is used for mips32
and mips64. This had a number of problems:
1) Storing and loading byte and halfword quantities for mips16 has particular
problems due to the primarily non mips16 nature of SP. When we must
load/store byte/halfword stack objects in a function, we must create a mips16
alias register for SP. This functionality is tested in stchar.ll.
2) We need to have an FP register under certain conditions (such as
dynamically sized alloca). We use mips16 register S0 for this purpose.
In this case, we also use this register when accessing frame objects so this
issue also affects the complex pattern addr16. This functionality is
tested in alloca16.ll.
The Mips16InstrInfo.td has been updated to use addr16 instead of addr.
The complex pattern C++ function for addr has been copied to addr16 and
updated to reflect the above issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166897 91177308-0d34-0410-b5e6-96231b3b80d8
2. As part of this, added assembly format FEXT_RI16_SP_explicit_ins and
moved other lines for FEXT_RI16 formats to be in the right place in the code.
3. Added mayLoad and mayStore assignements for the load/store instructions added and for ones already there that did not have this assignment.
4. Another patch will deal with the problem of load/store byte/halfword to the stack. This is a particular Mips16 problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164811 91177308-0d34-0410-b5e6-96231b3b80d8
use load/store fragments defined in TargetSelectionDAG.td in place of them.
Unaligned loads/stores are either expanded or lowered to target-specific nodes,
so instruction selection should see only aligned load/store nodes.
No changes in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163960 91177308-0d34-0410-b5e6-96231b3b80d8
or not it is in mips16 mode. Define MipsPseudo (mode-independant pseudo) and
PseudoSE (mips32/64 pseudo) classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161071 91177308-0d34-0410-b5e6-96231b3b80d8