In a `__asm` block, a symbol reference is usually a memory constraint
(indirect TargetLowering::C_Memory) [LOOP]. CALL and JUMP instructions are special
that `__asm call k` can be an address constraint, if `k` is a function.
Clang always gives us indirect TargetLowering::C_Memory and need to convert it
to direct TargetLowering::C_Address. D133914 implements this conversion, but
does not consider JMP or case-insensitive CALL. This patch implements the missing
cases, so that `__asm jmp k` (`jmp ${0:P}`) will correctly lower to `jmp _k`
instead of `jmp dword ptr [_k]`.
(`__asm call k` lowered to `call dword ptr ${0:P}` and is fixed by D149695 to
lower to `call ${0:P}` instead.)
[LOOP]: Some instructions like LOOP{,E,NE} and Jcc always use an address
constraint (`loop _k` instead of `loop dword ptr [_k]`).
After this patch and D149579, all the following cases will be correct.
```
int k(int);
int (*kptr)(int);
...
__asm call k; // correct without this patch
__asm CALL k; // correct, but needs this patch to be compatible with D149579
__asm jmp k; // correct, but needs this patch to be compatible with D149579
__asm call kptr; // will be fixed by D149579. "Broken case" in clang/test/CodeGen/ms-inline-asm-functions.c
__asm jmp kptr; // will be fixed by this patch and D149579
```
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D149920
We were modeling these as if the index type was always e8, but the actual
lowering uses the data type width if legal. We also weren't accounting for
i64 on xlen32 correctly.
Noticed via inspection while working on the shuffle/buildvec lowering. Note
that this costing is also wrong in a more major way - we don't actually use
a constant pool load in many cases. But that's a separate issue.
Move the fold from X86 to generic expansion
(We also have several existing expansions that are missing freezes on repeated operands - I've added a TODO for now).
Based on the following description from Andrew W.
Instructions not mentioned here behave the same as integer ALU ops
rev8 only executes in the late-A and late-B ALUs
shNadd[.uw] only execute on the early-B and late-B ALUs
clz[w], ctz[w], and orc.b and all rotates only execute in the late-B ALU
pcnt[w] looks exactly like integer multiply
This patch does not account for early/late ALU in the model. It is coded based
on the pipes only.
Co-Authored-By: topperc <craig.topper@sifive.com>
Differential Revision: https://reviews.llvm.org/D149497
The Zcmt instructions overlap encoding space with some C extension
instructions. Isolate to a separate namespace.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D149891
This intrinsic is meant to lower directly to the i8x16.shuffle instruction,
which takes its lane index arguments as immmediates. The ISel for the intrinsic
assumed that the lane index arguments were constants, so bitcode that
"incorrectly" used this intrinsic with non-immediate arguments caused an
assertion failure in the backend.
Avoid the crash by defining the lane index arguments to be immediates, matching
the underlying instruction. Update ISel accordingly. This change means that the
bitcode that previously caused a crash will now fail to validate.
Fixes#55559.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D149898
Based on the following description from Andrew W.
- Instructions not mentioned here behave the same as integer ALU ops
- rev8 only executes in the late-A and late-B ALUs
- shNadd[.uw] only execute on the early-B and late-B ALUs
- clz[w], ctz[w], and orc.b and all rotates only execute in the late-B ALU
- pcnt[w] looks exactly like integer multiply
This patch does not account for early/late ALU in the model. It is coded based
on the pipes only.
Differential Revision: https://reviews.llvm.org/D149497
Co-Authored-By: topperc <craig.topper@sifive.com>
If vector has two different values and it can be splitted into two sub
vectors with same length, generate two DUP and CONCAT_VECTORS/VECTOR_SHUFFLE.
For example,
t22: v16i8 = BUILD_VECTOR t23, t23, t23, t23, t23, t23, t23, t23,
t24, t24, t24, t24, t24, t24, t24, t24
==>
t26: v8i8 = AArch64ISD::DUP t23
t28: v8i8 = AArch64ISD::DUP t24
t29: v16i8 = concat_vectors t26, t28
Differential Revision: https://reviews.llvm.org/D148347
Emit FNMADD instead of FNEG(FMADD) for optimization levels
above Oz when fast-math flags (nsz+contract) permit it.
Differential Revision: https://reviews.llvm.org/D149260
Instead of equality comparison of value to preferred zero we can check just
the sign of value and if sign is set we should put this value as second operand for minimum
and first operand for maximum.
In this case FMIN/FMAX will choose the right result for 0.f and -0.f comparison.
This allows us:
1. avoid loading of big 64-bit constant for fminimum.
2. for double on non-64-nib platform we need to check only high part of value.
3. test against zero to check sign takes less size of instruction
Additionally, if we know that any of value is guaranteed to be non-zero
we should not care about 0.f and -0.f comparison.
Reviewed By: e-kud
Differential Revision: https://reviews.llvm.org/D149812
After applying FMIN/FMAX, if any of operands is NaN, the second operand will be the result.
So all we need is to check whether first operand is NaN and return it or result of FMIN/FMAX.
So we avoid usage of constant NaN in the lowering.
Additionally we can avoid handling NaN after FMIN/FMAX if we are sure that first operand is not NaN.
Reviewed By: e-kud
Differential Revision: https://reviews.llvm.org/D149729
Emit FNMADD instead of FNEG(FMADD) for optimization levels
above Oz when fast-math flags (nsz+contract) permit it.
Differential Revision: https://reviews.llvm.org/D149260
Make sure that the upper bits of the offset is placed in bits 20-21 of the
instruction word.
This fixes the encoding of backwards (negative offset) BPr branches.
(Previously, the upper two bits of the offset would overwrite parts of the rs1
field, causing it to branch on the wrong register, with the wrong offset)
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D144012
Otherwise I think we extract and use a build_vector. There may be
some more improvements that can be made and there might be some
cases that we should do something different for, but this seemed like a
decent starting point.
Reviewed By: luke
Differential Revision: https://reviews.llvm.org/D149724
This change will allow to put code pointers in DWARF info fields that are larger than actual pointer size, e.g. 16-bit pointers into 32-bit fields.
The need for this came up while creating support for MSP430 in LLDB. MSP430-GCC already generates DWARF info with 32-bit fields, so this change is necessary for LLDB to maintain compatibility with both GCC and LLVM binaries. Moreover, right now in LLDB there is no support for having DWARF pointer size different from ELF header type, e.g. 16-bit DWARF info within ELF32, and it seems there is no such thing as ELF16.
Since other mainline targets are made to have the same pointer size in both MCAsmInfo and DataLayout, there is no need to change anything there.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D148042
The AOK_SizeDirective part from 5b37c181291210bedfbb7a6af5d51229f3652ef0
(2014-08) seems unneeded nowadays (the root cause has likely been fixed
elsewhere). The part abuses that `call dword ptr foo` assembles the same way as `call
foo` in Intel syntax, which is going to be fixed (changed) by D149579.
The generated object files for
CodeGen/ms-inline-asm{,-functions,-variables,-static-variable}.c and
CodeGenCXX/ms-inline-asm-fields.cpp are unchanged
(-mno-incremental-linker-compatible) with just this patch. When D149579 is
subsequently applied, the FIXME part of `kptr` in
CodeGen/ms-inline-asm-functions.c will be fixed.
Differential Revision: https://reviews.llvm.org/D149695
This patch mostly adapts the existing AMDGPUCtorDtorLoweringPass for use
by the Nvidia backend. This pass transforms the ctor / dtor list into a
kernel call that can be used to invoke those functinos. Furthermore, we
emit globals such that the names and addresses of these constructor
functions can be found by the driver. Unfortunately, since NVPTX has no
way to emit variables at a named section, nor a functioning linker to
provide the begin / end symbols, we need to mangle these names and have
an external application find them.
This work is related to the work in D149398 and D149340.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D149451
It looks like the intention here is to truncate a XLenVT -> i1, in
which case we should be emitting snez instead of sneq if I'm understanding
correctly.
Reviewed By: jacquesguan, frasercrmck
Differential Revision: https://reviews.llvm.org/D149732
GotPltSectionVA is specific to x86-32 PIC PLT entries.
Let's remove the argument from the generic interface.
As a side effect of not requiring .got.plt, this simplification
addresses a subset of https://github.com/llvm/llvm-project/issues/62537
by enabling .plt dumping for some ld.bfd -z now linked x86-32/x86-64 images
without .got.plt
The wasm64 versions of the v128.storeX_lane instructions was incorrectly defined
as returning a v128 value, which resulted in spurious drop instructions being
emitted and causing validation to fail. This was not caught earlier because
wasm64 has been experimental and not well tested. Update the relevant test file
to test both wasm32 and wasm64.
Fixes#62443.
Differential Revision: https://reviews.llvm.org/D149780
A DBG_VALUE or DBG_VALUE_LIST must always return a non-null
DILocalVariable, the ARMLoadStoreOptimizer code that move’s DBG_VALUE
and DBG_VALUE_LIST instructions if their corresponding loads have been
moved, currently just continues if it finds a DBG_VALUE or
DBG_VALUE_LIST with a null DILocalVariable, change that to an assert.
Differential revision: https://reviews.llvm.org/D149762
Re-land D145441 with data layout upgrade code fixed to not break OpenMP.
This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.
Differential Revision: https://reviews.llvm.org/D149776
