This MIPS behavior from edb9d84dcc4824865e86f963e52d67eb50dde7f5 (2010)
is obsoleted and misleading. This caused confusion in
https://reviews.llvm.org/D123702 ([NVPTX] Disable parens for identifiers
starting with '$')
Note: $tmp was rejected by AsmParser before
https://reviews.llvm.org/D75111 (2020)
Set it to true only if isInt<16>.
By default implemention defines them to true always. For most cases,
MIPS uses 16bit IMM, and for microMIPS, ICMP and ADDiu have 16bit IMM
flavors.
Relands #132907 with a fix in the testcase:
clang/test/CodeGen/Mips/subtarget-feature-test.c
enable this test for only mips64 target
PR #130587 defined same SubTargetFeature for CPUs i6400 and i6500 which
resulted into following warning when -mcpu=i6500 was used:
+i6500' is not a recognized feature for this target (ignoring feature)
This PR fixes above issue by defining separate SubTargetFeature for
i6500.
Set `addiu` as `isAsCheapAsAMove` only when the src register or imm is
zero only.
If other cases are set `isAsCheapAsAMove`, MachineLICM will reject to
hoist it.
PR #130587 defined same SubTargetFeature for CPUs i6400 and i6500 which
resulted into following warning when -mcpu=i6500 was used:
+i6500' is not a recognized feature for this target (ignoring feature)
This PR fixes above issue by defining separate SubTargetFeature for
i6500.
So that LoopStrengthReduce can work for MIPS.
The code is copied from RISC-V.
---------
Co-authored-by: qethu <190734095+qethu@users.noreply.github.com>
Follow the X86 renaming.
> "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation.
> "Relocation specifier" is clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly.
In addition, rename MipsMCExpr::getKind, which confusingly shadows the base class getKind.
The i6400 and i6500 are high performance multi-core microprocessors from
MIPS that provide best in class power efficiency for use in
system-on-chip (SoC) applications. i6400 and i6500 implements Release 6
of the MIPS64 Instruction Set Architecture with full hardware
multithreading and hardware virtualization support.
Target shouldForceRelocation checks `FirstLiteralRelocationKind` to
determine whether a relocation is forced due to the .reloc directive. We
should move the code to evaluateFixup so that many targets don't need to
override shouldForceRelocation.
In `.equ a, 3; .if a@plt`, a@plt does not evaluate to an absolute value
(MCExpr::evaluateAsRelocatableImpl disables evaluation when the Kind !=
0 at parse time). Similarly, when using MCTargetValue,
evaluateAsAbsolute should return false when MCValue::RefKind==0.
This allows us to remove `if (!Asm)` check from MipsMCExpr.cpp
(%hi(0xdeadbeef) is not evaluated to a constant without RefKind) and
make targets less error-prone.
After folding the inner expression, we might get something like
%hi(0x30124), MipsAsmBackend::applyFixup will apply the relocation
operator, so we don't need to duplicate code in MipsMCExpr
(introduced by https://reviews.llvm.org/D19716).
While we don't know the encoding at parse time (see hilo-addressing.s),
it is not an issue.
This change also removes an inappropriate use of `Fixup`
(introduced in 2014 by 752b91bd821ad8a23e004b6cd631ae4f6984ae8b ; which
will go away with my next change).
In addition, fix a crash by porting the fix from RISCV.
```
lui $4, %hi(und-$L3)
```
fixELFSymbolsInTLSFixups walks the expression tree, which is complex and
unnecessary. As the expression must be relocatable, we can move the code
to getRelocType and just set SymA. The behavior is similar to GNU
assembler.
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.
For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.
The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.
The StringRef overload is often error-prone as users might forget to
register the MCSymbol.
Add comments to MCTargetExpr and MCSymbolRefExpr::VariantKind.
In the distant future the VariantKind parameter might be removed.
https://reviews.llvm.org/D23669 inappropriately added MIPS-specific
dtprel/tprel directives to MCStreamer. In addition,
llvm-mc -filetype=null parsing these directives will crash.
This patch moves these functions to MipsTargetStreamer and fixes
-filetype=null.
gprel32 and gprel64, called by AsmPrinter, are moved to
MCTargetStreamer.
A relocation expression might be used in an immediate operand or a
memory offset. https://reviews.llvm.org/D23110 , which intended to
generalize chained relocation operators (%hi(%neg(%gp_rel(x)))),
inappropriated introduced intrusive changes to the generic code. This
patch drops the intrusive changes and significantly simplifies the code.
The new style is similar to pre-D23110 but much cleaner.
Some weird expressions allowed by gas are not supported for simplicity,
e.g. "%lo foo", "(%lo(foo))", "%lo(foo)+1".
"(%lo(foo))", while previously parsed, is not used in practice.
"%lo(foo)+1" and "%lo(2*4)+foo" were previously parsed but would lead to
an error anyway as the expression is not relocatable
(`evaluateSymbolicAdd` does not fold the Add when RefKind are
different).
e.g.
`addiu $t2, $t3, .Lend-.Lstart-4`
used by libdragon/boot/boot_trampoline.S
To make this work, update a few places:
* AsmParser: When matching a isSImm/isUImm, consider an expression
that does not evaluate to an assemble-time constant an immediate.
* MCCodeEmitter: If this is an I-type instruction and the expression
does not evaluate to an assemble-time constant, append a
`fixup_Mips_AnyImm16`.
TODO: in MipsInstrInfo.td, more `Operand` should switch from the
default `getMachineOpValue` to `getImmOpValue` like RISCV.
* AsmBackend: If the expression does not evaluate to a constant
with assembler layout information, report "unknown relocation type"
like X86. If the result is not within [-32768,65535] (the bound gas
uses when parsing a constant integer for ADDIU)
Fix#126531
Pull Request: https://github.com/llvm/llvm-project/pull/127581
NVPTX, SPIRV, and WebAssembly pass virtual registers to this function
since they don't perform register allocation. We need to use Register to
avoid a virtual register being converted to MCRegister by the caller.
Callee saved registers should always be phyiscal registers. They are
often passed directly to other functions that take MCRegister like
getMinimalPhysRegClass or TargetRegisterClass::contains.
Unfortunately, sometimes the MCRegister is compared to a Register which
gave an ambiguous comparison error when the MCRegister is on the LHS.
Adding a MCRegister==Register comparison operator created more ambiguous
comparison errors elsewhere. These cases were usually comparing against
a base or frame pointer register that is a physical register in a
Register. For those I added an explicit conversion of Register to
MCRegister to fix the error.
The llvm.readcyclecounter intrinsic can be implemented via the `rdhwr
$2, $hwr_cc` instruction.
$hwr_cc: High-resolution cycle counter. This register provides read
access to the coprocessor 0 Count Register.
Fix#106318.
The llvm.readcyclecounter intrinsic can be implemented via the `rdhwr
$3, $hwr_cc` instruction.
$hwr_cc: High-resolution cycle counter. This register provides read
access to the coprocessor 0 Count Register.
Fix#106318.
This is needed for architectures that actually use strict pointer
arithmetic instead of integers such as AArch64 with FEAT_CPA (see
https://github.com/llvm/llvm-project/pull/105669) or CHERI. Using an
index as the first operand of pointer arithmetic may result in an
invalid output.
While there are quite a few codegen changes here, these only change the
order of registers in add instructions. One MIPS combine had to be
updated to handle the new node order.
Reviewed By: topperc
Pull Request: https://github.com/llvm/llvm-project/pull/125279
In function handleMFLOSlot, we may get a variable LastInstInFunction
with a value of true from function getNextMachineInstr and IInSlot may
be null which would trigger an assert.
So we need to skip this case.
Fix#118223.
- Widen v2i8, v2i16 and v2i32 vectors so they don't cast back and forth,
and make sure that instructions with correct data unit is being used.
- Handle undef indices for VSHF when lowering VECTOR_SHUFFLE (it crashes
if such index is present).
This patch is in preparation to enable setting the MachineInstr::MIFlag
flags, i.e. FrameSetup/FrameDestroy, on callee saved register
spill/reload instructions in prologue/epilogue. This eventually helps in
setting the prologue_end and epilogue_begin markers more accurately.
The DWARF Spec in "6.4 Call Frame Information" says:
The code that allocates space on the call frame stack and performs the
save
operation is called the subroutine’s prologue, and the code that
performs
the restore operation and deallocates the frame is called its epilogue.
which means the callee saved register spills and reloads are part of
prologue (a.k.a frame setup) and epilogue (a.k.a frame destruction),
respectively. And, IIUC, LLVM backend uses FrameSetup/FrameDestroy flags
to identify instructions that are part of call frame setup and
destruction.
In the trunk, while most targets consistently set
FrameSetup/FrameDestroy on save/restore call frame information (CFI)
instructions of callee saved registers, they do not consistently set
those flags on the actual callee saved register spill/reload
instructions.
I believe this patch provides a clean mechanism to set
FrameSetup/FrameDestroy flags on the actual callee saved register
spill/reload instructions as needed. And, by having default argument of
MachineInstr::NoFlags for Flags, this patch is a NFC.
With this patch, the targets have to just pass FrameSetup/FrameDestroy
flag to the storeRegToStackSlot/loadRegFromStackSlot calls from the
target derived spillCalleeSavedRegisters and restoreCalleeSavedRegisters
to set those flags on callee saved register spill/reload instructions.
Also, this patch makes it very easy to set the source line information
on callee saved register spill/reload instructions which is needed by
the DwarfDebug.cpp implementation to set prologue_end and epilogue_begin
markers more accurately.
As per DwarfDebug.cpp implementation:
prologue_end is the first known non-DBG_VALUE and non-FrameSetup
location
that marks the beginning of the function body
epilogue_begin is the first FrameDestroy location that has been seen in
the
epilogue basic block
With this patch, the targets have to just do the following to set the
source line information on callee saved register spill/reload
instructions, without hampering the LLVM's efforts to avoid adding
source line information on the artificial code generated by the
compiler.
<Foo>InstrInfo::storeRegToStackSlot() {
...
DebugLoc DL =
Flags & MachineInstr::FrameSetup ? DebugLoc() : MBB.findDebugLoc(I);
...
}
<Foo>InstrInfo::loadRegFromStackSlot() {
...
DebugLoc DL =
Flags & MachineInstr::FrameDestroy ? MBB.findDebugLoc(I) : DebugLoc();
...
}
While I understand this patch would break out-of-tree backend builds, I
think it is in the right direction.
One immediate use case that can benefit from this patch is fixing
#120553 becomes simpler.
