We don't provide __extendhfxf2, and only have the soft-float
__extendhfsf2 in compiler-rt. This only changed recently with
655ba9c8a1d2, so this patch reverts back to the previous behavior.
However, the f80->f16 fptrunc is not easily implementable without
the compiler-rt __truncxfhf2, but that has always been true, and
isn't an immediate regression.
Patch by Ahmed Bougacha.
rdar://102194995
Frame lowering inserts scalar addition to compute the offset to the
stack objects. This instructions inserted in arbitrary place and may clobber
SCC between its definition and S_CSELECT_B32 instruction. This change
workarounds this particular code pattern. It queries the scavenger for SGPR and
if available saves SCC to it and restore its value after frame lowering code
insertion.
Reviewed By: foad
Differential Revision: https://reviews.llvm.org/D136169
In AArch64 backend X30 is named as LR, X29 is named as FP. So the code in AArch64Subtarget::AArch64Subtarget can't recognize these 2 registers.
for (unsigned i = 0; i < 31; ++i) {
if (ReservedRegNames.count(TRI->getName(AArch64::X0 + i)))
ReserveXRegisterForRA.set(i);
}
This patch add code to explicitly handle these 2 registers.
Differential Revision: https://reviews.llvm.org/D137810
This patch adds spilling for the new WACC registers.
In order to get the spilling test to work the MMA instructions from Power 10 are
now supported for Future CPU except that they are all using the new WACC
registers instead of the ACC registers from Power 10.
Reviewed By: amyk, saghir
Differential Revision: https://reviews.llvm.org/D136728
When performing shrinking int/fp conversions the predicate should
be created to match the original fixed length vector type so the
unused lanes don't trigger side effects.
This patch also includes related refactoring to better detect such
issues and streamline the code a little.
Differential Revision: https://reviews.llvm.org/D138351
Summary: -xcoff-traceback-table is a default option on AIX regardless of optimization and debug levels. An error of relocation for paired relocatable term is not yet supported in XCOFFObjectWriter::recordRelocation occurred when both of the -xcoff-traceback-table and -function-sections are enabled.
The root cause is that we missed to calculate the symbols difference as absolute value before adding fixups when symbol_A without the fragment set is the csect itself and symbol_B is in it.
This patch only sets the fragment for XMC_PR csects because we don't have other cases that hit this problem yet.
Reviewed By: DiggerLin, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D137230
This patch add the support of RISCV Zca ext
`Zca` is a subset of C extension instructions that are compatible with the Zc extension.
So this patch implements Zca code generation with reference to the C extension and sets the 2-byte alignment for the Zca extension, just like C extension does.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D130483
As discussed in D137541, it supports processing when the depth of
__builtin_frame_address is greater than 0 instead of reporting an error.
Unsafe calls rely on the '-Wframe-address' option for diagnosis.
Differential Revision: https://reviews.llvm.org/D138084
This patch is an alternative of D100091. It solved the problems in `f80` type lowering.
Reviewed By: LuoYuanke
Differential Revision: https://reviews.llvm.org/D137946
This disables `RegisterCoalescer` pass at -O1, which currently runs for
all levels except for -O0, as a part of common optimization pipeline.
`RegisterCoalescer` pass degrades Wasm debug info quality by a
significant margin. When I use `LiveDebugValue` analysis, disabling this
increases the average PC ranges covered by 15% on Emscripten core
benchmarks (52% -> 66.8%). (Our code is currently not using
`LiveDebugValues` analysis at the moment, and the experiment was done on
a local setting that enabled it. I'm planning to upstream it soon.)
In Emscripten core benchmarks, disabling this at -O1 causes +4.5% in
code size and +1% in the number of locals. The number of globals stays
the same. I believe this tradeoff is acceptable given that -O1 is not
usually used in production builds and is often used for debugging when
the application size is very large.
The plan is to investigate and fix what's causing the degradation in
that pass, but for now disabling it seems like a low-hanging quick fix.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D138455
Adds some more code to GlobalISel to enable instruction selection for and/or/xor.
- Makes G_IMPLICIT_DEF, G_CONSTANT, G_AND, G_OR, G_XOR legal for 64bit register size.
- Implement lowerReturn in CallLowering
- Provides mapping of the operands to register banks.
- Adds register info to G_COPY operands.
The utility functions are all only implemented so far to support this use case.
Especially the functions in PPCGenRegisterBankInfo.def are too simple for
general use.
Reviewed By: nemanjai, shchenz, amyk
Differential Revision: https://reviews.llvm.org/D127530
This matches what we get for something like.
%0 = shl i32 %x, C
%1 = zext i32 %0 to i64
%2 = getelementptr i32, ptr %y, %1
The shift before the zext and the shift implied by the GEP get
combined with an AND after them. We need to split it back into
2 shifts so we can fold one into shXadd.uw.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D137886
We already do this for most cases, with the exception of instructions that
get expanded to function calls (e.g. for lowering operations on fp128
values), in which case we temporarily allocate a lazy-save buffer.
The code that is generated in this case, is however incorrect, as it seems
to pass an incorrect address for the TPIDR2 object to the ZA restore
function. By always allocating the lazy-save buffer once, we avoid this
issue entirely.
The cost is that we also allocate such a buffer when it is not
needed. We could fix that in a follow-up patch, where we remove the
lazy-save buffer when it isn't used.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D138208
We generate erroneous trace for a basic block if it does not have at least one
predecessor when MinInstr strategy is used. Currently only this strategy is
implemented, so we always have a wrong trace for any entry block. This results in
wrong instructions heights calculation and also leads to wrong critical path.
The described behavior is demonstrated on a simple test. It shows that early
if-conv pass makes wrong decisions due to incorrectly calculated critical path
lenght.
Differential Revision: https://reviews.llvm.org/D138272
When there is not GRS or MOVIH/ORI instruction, we can not get the address of
ConstantPool entry directly. So we need put the address into ConstantPool to leverage CSKY::LRW instruction.
This option was enabled in D128582, and whilst it seems to be a net
improvement in many cases, at least a couple of issues have been
reported from D135957 and from the CSE added to the backend causing more
instructions in executed blocks. Revert for the time being, until we can
improve the precision.
This patch adds tail call support to the LoongArch backend. When
appropriate, use the `b` or `jr` instruction for tail calls (the
`pcalau12i+jirl` instruction pair when use medium codemodel).
This patch also modifies the inappropriate operand name:
simm26_bl -> simm26_symbol
This has been modeled after RISCV's tail call opt.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137889
When all registers have been allocated and CFR needs to be saved on the
stack, an emergency spill slot is required. Because CFR's spill and
reload require a general purpose register to transfer.
The attached test case was bugpoint-reduced down from
`MultiSource/Benchmarks/mafft/Lalignmm.c` in the test-suite.
Without this patch, llc will crash and report the following errors:
```
LLVM ERROR: Error while trying to spill R4 from class GPR: Cannot scavenge register without an emergency spill slot!
```
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D138007
If LogicNonShiftReg is the same to Shift1Base, and shift1 const is the same to MatchInfo.Shift2 const, CSEMIRBuilder will reuse the old shift1 when build shift2.
So, if we erase MatchInfo.Shift2 at the end, actually we remove old shift1. And it will cause crash later.
Solution for this issue is just erase it earlier to avoid the crash.
Fix#58423
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138187
Copies the same transform from the DAG. Helps eliminate some codegen
diffs to allowed shared checks in a future change.
Not sure if apply supports anything better than C++ fragments for
the result. It's also not really reasonable that every combine has
to set the default insertion point.
