to an infinite loop because of the def-use chains.
Also use a frame load instead of store for the LD instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141263 91177308-0d34-0410-b5e6-96231b3b80d8
This restores my karma after I added TRI::getSubClassWithSubReg().
Register constraints are applied 'backwards'. Starting from the
register class required by an instruction operand, the correct question
is: 'How can I constrain the super-register register class so all its
sub-registers satisfy the instruction constraint?' The
getMatchingSuperRegClass() hook answers that.
We never need to go 'forwards': Starting from a super-register register
class, what register class are the sub-registers in? The
getSubRegisterRegClass() hook did that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141258 91177308-0d34-0410-b5e6-96231b3b80d8
merging an lsl #2 that has multiple uses on A9. This shift is free, so there is
no problem merging it in multiple places. Other unprofitable shifts will not be
merged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141247 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, prefix multiclass template arg names with the
multiclass name followed by "::" to avoid name clashes among
multiclass arguments and other entities in the multiclass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141239 91177308-0d34-0410-b5e6-96231b3b80d8
Process each multidef declared in a multiclass. Iterate through the
list and instantiate a def in the multiclass for each item, resolving
the list item to the temporary iterator (possibly) used in the
multidef ObjectBody. We then process each generated def in the normal
way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141233 91177308-0d34-0410-b5e6-96231b3b80d8
Add parser support to recognize multidefs. No processing on the
multidef is done at this point. The grammar is:
MultiDef = MULTIDEF ObjectName < Value, Declaration, Value > ObjectBody
The first Value must be resolveable to a list and the second Value
must be resolveable to an integer. The Declaration is a temporary
value used as an iterator to refer to list items during processing.
It may be passed into the ObjectBody where it will be substituted with
the list value used to instantiate each def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141232 91177308-0d34-0410-b5e6-96231b3b80d8
Add a set of data structures and members analogous to those used for
multiclass defs. These will represent a new kind of multiclass def: a
multidef. The idea behind the multidef is to process a list of items
and create a def record for each one inside the enclosing multiclass.
This allows the user to dynamically create a set of defs based on the
contents of a list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141230 91177308-0d34-0410-b5e6-96231b3b80d8
Move the code to instantiate a multiclass def, bind its arguments and
resolve its members into three helper functions. These will be reused
to support a new kind of multiclass def: a multidef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141229 91177308-0d34-0410-b5e6-96231b3b80d8
While I'm here, fix the related issue with strncmp, add some actual tests for strcmp and strncmp, and start using StringRef::compare for constant folding instead of using strcmp/strncmp so that the optimized IR isn't dependent on the host's implementation of strcmp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141227 91177308-0d34-0410-b5e6-96231b3b80d8
to the landing pad. This will be used by the back-end to generate the jump
tables for dispatching the arriving longjmp in sjlj eh.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141224 91177308-0d34-0410-b5e6-96231b3b80d8
PhysReg operands are not allowed to have sub-register indices at all.
For virtual registers with sub-reg indices, check that all registers in
the register class support the sub-reg index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141220 91177308-0d34-0410-b5e6-96231b3b80d8
Just pull the instruction name, but don't change the order of anything
else. That keeps --debug happy and non-crashing, but doesn't change
how the worklist gets built.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141210 91177308-0d34-0410-b5e6-96231b3b80d8
EXTRACT_SUBREG is emitted as %dst = COPY %src:sub, so there is no need to
constrain the %dst register class. RegisterCoalescer will apply the
necessary constraints if it decides to eliminate the COPY.
The %src register class does need to be constrained to something with
the right sub-registers, though. This is currently done manually with
COPY_TO_REGCLASS nodes. They can possibly be removed after this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141207 91177308-0d34-0410-b5e6-96231b3b80d8
There are fewer registers with sub_8bit sub-registers in 32-bit mode
than in 64-bit mode. In 32-bit mode, sub_8bit behaves the same as
sub_8bit_hi.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141206 91177308-0d34-0410-b5e6-96231b3b80d8
When updating the worklist for InstCombine, the Add/AddUsersToWorklist
functions may access the instruction(s) being added, for debug output for
example. If the instructions aren't yet added to the basic block, this
can result in a crash. Finish the instruction transformation before
adjusting the worklist instead.
rdar://10238555
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141203 91177308-0d34-0410-b5e6-96231b3b80d8
The register class created by INSERT_SUBREG and SUBREG_TO_REG must be
legal and support the SubIdx sub-registers.
The new getSubClassWithSubReg() hook can compute that.
This may create INSERT_SUBREG instructions defining a larger register
class than the sub-register being inserted. That is OK,
RegisterCoalescer will constrain the register class as needed when it
eliminates the INSERT_SUBREG instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141198 91177308-0d34-0410-b5e6-96231b3b80d8
TwoAddressInstructionPass should annotate instructions with <undef>
flags when it lower REG_SEQUENCE instructions. LiveIntervals should not
be in the business of modifying code (except for kill flags, perhaps).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141187 91177308-0d34-0410-b5e6-96231b3b80d8
