Add three more special cases for loading registers with immediates.
The first allows values in the range of [-255, 255] to be loaded with
MOVEQ, even if the register is more than 8 bits and the sign extention
is unwanted. This is done by loading the bitwise complement of the
desired value, then performing a NOT instruction on the loaded register.
This special case is only used when a simple MOVEQ cannot be used, and
is only used for 32 bit data registers. Address registers cannot support
MOVEQ, and the two-instruction sequence is no faster or smaller than a
plain MOVE instruction when loading 16 bit immediates on the 68000, and
likely slower for more sophisticated microarchitectures. However, the
instruction sequence is both smaller and faster than the corresponding
MOVE instruction for 32 bit register widths.
The second special case is for zeroing address registers. This simply
expands to subtracting a register with itself, consuming one instruction
word rather than 2-3, with a small improvement in speed as well.
The last special case is for assigning sign-extended 16-bit values to a
full address register. This takes advantage of the fact that the movea.w
instruction sign extends the output, permitting the immediate to be
smaller. This is similar to using lea with a 16-bit address, which is
not added in this patch as 16-bit absolute addressing is not yet
implemented.
This is a v2 submission of #90817. It also creates a 'Data' test
directory to better align with the backend's tablegen layout.
The renamable flag is useful during MachineCopyPropagation but renamable
flag will be dropped after lowerCopy in some case.
This patch introduces extra arguments to pass the renamable flag to
copyPhysReg.
Add support for the moveq instruction, which is both faster and smaller
(1/2 to 1/3 the size) than a move with immediate to register.
This change introduces the instruction, along with a set of
pseudoinstructions to handle immediate moves to a register that is
lowered post-RA.
Pseudos are used as moveq can only write to the full register, which
makes
matching i8 and i16 immediate loads difficult in tablegen. Furthermore,
selecting moveq before RA constrains that immediate to be moved into a
data
register, which may not be optimal.
The bulk of this change are fixes to existing tests, which cover the new
functionality sufficiently.
This patch introduces TLS (Thread-Local Storage) support to the LLVM m68k backend.
Reviewed By: glaubitz
Differential Revision: https://reviews.llvm.org/D144941
In order to use the -stop-before/after infrastructure. Also remove the
creator function for M68kConvertMOVToMOVMPass, which has never been
created.
NFC.
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
With D134950, targets get notified when a virtual register is created and/or
cloned. Targets can do the needful with the delegate callback. AMDGPU propagates
the virtual register flags maintained in the target file itself. They are useful
to identify a certain type of machine operands while inserting spill stores and
reloads. Since RegAllocFast spills the physical register itself, there is no way
its virtual register can be mapped back to retrieve the flags. It can be solved
by passing the virtual register as an additional argument. This argument has no
use when the spill interfaces are called during the greedy allocator or even the
PrologEpilogInserter and can pass a null register in such cases.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138656
`MOVEM` is used to spill the register, which will cause problem with 1 byte data, since it only supports word (2 bytes) and long (4 bytes) size.
We change to use the normal `move` instruction to spill 1 byte data.
Fixes#57660
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D133636
Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D126349
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
At the moment `getMCInstrBeads` is forward-declared in a few places,
bring this together into a single header file.
This was done as part of the disassembler work, since the disassembler
would otherwise add one more forward declaration.
Differential Revision: https://reviews.llvm.org/D98533
