PHI operands and results must belong to the same register class.
If a PHI node produces an SGPR, but one of its operands is a VGPR, we
insert a VGPR-to-SGPR copy in the operand’s source block. The PHI
operand is then updated to use the destination register of the inserted
copy.
These inserted copies are processed immediately when they are created.
Therefore, we should avoid reprocessing them when handling their parent
block later.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
This follows up commit 7af2b51e761f499, which removed the BTI at the
start of functions with internal linkage (provided they weren't
indirectly called inside the translation unit) for Linux targets.
Now we leave out the BTI for any ELF target, including bare-metal,
because the AAELF64 document in the Arm ABI has been updated to make the
same guarantee as SYSVABI64: if the linker wants to insert an indirect
branch at link time (e.g. as part of a long branch thunk) it's
responsible for making a BTI-equipped landing pad.
That was too difficult to test in the existing codegen test
`patchable-function-entry-bti.ll`, because so much of LLVM's detailed
asm output changes for non-ELF targets. So I've simplified that back to
how it was before 7af2b51e761f499 (except that now it expects no BTI in
the disputed function), and made a new test checking specifically the
difference in BTI between the formats.
Patch removes the restriction for the revectorization of the previously
vectorized scalars in split nodes, and moves the cost profitability
check to avoid regressions.
Reviewers: hiraditya, RKSimon
Reviewed By: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/134286
Need to check, that the mask of the potentially matching splat node is
not less defined than the requested mask to avoid poison propagation and
incorrect code.
Fixes#135113
Armv8.1-M Mainline architecture is supported by Clang's driver & LLVM's
ARM backend, but MC would report an 'Unknown Arch: armv8.1-m.main' error
when processing '.arch armv8.1-m.main' assembler directives.
This patch upstreams initial support for making function calls in CIR.
Function arguments and return values are not included to keep the patch
small for review.
Related to #132487
Add target feature for point sample acceleration and enable it for
relevant
targets.
Also add support to insert waitcnts where required when point sample
accel may
have occurred. This has implications for out of order returns, which is
why
extra waitcnts are required.
Add a VMEM_NOSAMPLER bit in the register masks to determine when
waitcnt is required.
SrcVecTy and DstVecTy are used without a null check, and originate from
a dyn_cast. This patch adjusts this to use a fixed cast, since it is not
checked for null before use otherwise, but is semantically guaranteed
from previous checks.
This commit is for #107569 and #126817.
Stop changing musttail's caller and callee's function signature when
calling convention is not swifttailcc nor tailcc. Verifier makes sure
musttail's caller and callee shares exactly the same signature, see
commit 9ff2eb1 and #54964.
Otherwise just make sure the return type is the same and then process
musttail like usual calls.
close#107569, #126817
Formatting this piece of code made the program crash.
```
class TypedVecListRegOperand<RegisterClass Reg, int lanes, string eltsize>
: RegisterOperand<Reg, "printTypedVectorList<" # lanes # ", '"
# eltsize # "'>">;
```
The line starting with the `#` was treated as a separate preprocessor
directive line. Then the code dereferenced a null pointer when it tried
to continue parsing the first line that did not end in a semicolon.
Now the 2 problems are fixed.
There is some code to make sure that C++ keywords that are identifiers
in the other languages are not treated as keywords. Right now, the kind
is set to identifier, and the identifier info is cleared. The latter is
probably so that the code for identifying C++ structures does not
recognize those structures by mistake when formatting a language that
does not have those structures. But we did not find an instance where
the language can have the sequence of tokens, the code tries to parse
the structure as if it is C++ using the identifier info instead of the
token kind, but without checking for the language setting. However,
there are places where the code checks whether the identifier info field
is null or not. They are places where an identifier and a keyword are
treated the same way. For example, the name of a function in
JavaScript. This patch removes the lines that clear the identifier
info. This way, a C++ keyword gets treated in the same way as an
identifier in those places.
JavaScript
New
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Old
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Java
New
```Java
enum union { ABC, CDE }
```
Old
```Java
enum
union { ABC, CDE }
```
This reverts commit 97dcbdef6089175c45e14fcbcf5c88b10233a79a.
This was found via a Coverity static analysis pass. There's no
indication this was being used incorrectly in practice, but there are
public interfaces which require `BR` to be non-null and valid, and `BR`
was not being initialized by the constructor.
This adds an in-class initializer for `BR` and some asserts, to be safe.
This feature largely models the same behavior as in C++11. It is
technically a breaking change between C99 and C11, so the paper is not
being backported to older language modes.
One difference between C++ and C is that things which are rvalues in C
are often lvalues in C++ (such as the result of a ternary operator or a
comma operator).
Fixes#96486
This was found via a Coverity static analysis pass. There's no
indication this was being used incorrectly in practice, but there are
public interfaces which require `BR` to be non-null and valid, and `BR`
was not being initialized by the constructor.
This adds an in-class initializer for `BR` and some asserts, to be safe.
Split from https://github.com/llvm/llvm-project/pull/133161
refactor the code to extract file helpers used in HTML generators for
use in other generators for clang-doc
This patch fixes the error where compiling with
-DLLVM_LINK_LLVM_DYLIB=ON broke the buildbot
Optimization of alloca instructions may lead to invalid alias tags.
Incorrect alias tags can result in incorrect optimization outcomes for
Fortran source code compiled by Flang with flags: `-O3 -mmlir
-local-alloc-tbaa -flto`.
This commit removes alias tags when memcpy optimization replaces two
arrays with one array, thus ensuring correct compilation of Fortran
source code using flags: `-O3 -mmlir -local-alloc-tbaa -flto`.
This commit is also a proposal to fix the reported issue:
https://github.com/llvm/llvm-project/issues/133984
---------
Co-authored-by: Shilei Tian <i@tianshilei.me>
This reverts commit 785e7f06ddb1ba36aa679d23436726dcf61f8afb.
It did not solve the problem with flang-aarch64-libcxx and caused
another failure with openmp-offload-amdgpu-runtime-2.
This is a follow up to f8ee58a3c, and improves code generation for the
XRivosVizip extension.
If we have a slide pair which could be a zipeven or zipodd if the
shuffle was widened, widen the shuffle and then mask the zipeven or
zipodd.
This is basically working around an order of matching issue; we match
the slide pair variants before trying widening. I considered whether we
should just widen slide pairs without any consideration of the zip
idioms, but the resulting codegen changes look mostly like churn, and
have no clear evidence of profitability.
The buidbot
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is
currently failing with an ABI issue. The suspected reason is that
LLVMSupport.a is built using libc++, but the unittests are using the
default C++ standard library, libstdc++ in this case. This predefined
`llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`,
which finds the libc++-built LLVMSupport.
To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake
such that everything that links to LLVM libraries use the same standard
library. In this case discussed in
https://github.com/llvm/llvm-zorg/pull/387 it was the flang-rt
unittests, but other runtimes with GTest unittests should have the same
issue (e.g. offload), and any external project that uses
`find_package(LLVM)`.
clspv is already handling generation of fp16. This implementation is
preventing clspv from making the best choice to use an emulation on top
of fp32-fma, or the native fp16-fma, depending on the command-line
arguments.
This is an alternative to
https://github.com/llvm/llvm-project/pull/122103
In SPIR-V, private global variables have the Private storage class. This
PR adds a new address space which allows frontend to emit variable with
this storage class when targeting this backend.
This is covered in this proposal: llvm/wg-hlsl@4c9e11a
This PR will cause addrspacecast to show up in several cases, like class
member functions or assignment. Those will have to be handled in the
backend later on, particularly to fixup pointer storage classes in some
functions.
Before this change, global variable were emitted with the 'Function'
storage class, which was wrong.
FP_ROUND and FP_EXTEND the input value before FABSing it. This avoids
some bit twiddling to copy the sign bit from the input to the result. It
does introduce one extra FABS, but that is folded into another
instruction for free on AMDGPU, which is the only target currently
affected by this change.
I've always found this hard to read. Some upcoming changes make similar
computations, so I thought it's a good time to factor out this logic
into re-usable helpers and clean it up using LLVM's preferred
early-return style.
