| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements avr-gcc's calling convention:
https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D120720
(cherry picked from commit 86c1d075bb32101fe1c403e873ce33945bfa9626)
|
|
|
|
|
|
|
|
|
|
| |
Synchronize AVR device lists with gcc-avr-5.4.0 and avr-libc-2.0.0.
Reviewed By: dylanmckay, aykevl
Differential Revision: https://reviews.llvm.org/D121359
(cherry picked from commit 6edfe45a63125a8938a5bea13534a118b0e31023)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since D110065, the 'R' profile support is added to LLVM. It turns the
`generic` cpu into the intersection of v8-a and v8-r. However, this
makes some backward compatibility problems. The original patch makes
the clang driver implicitly pass -march=armv8-a when only the triple
is specified. Since it only applies to clang, other tools like
llvm-objdump still faces the backward compatibility problem.
This patch applies the same idea to MC related tools by enabling '+v8a'
feature when nothing is specified (both CPU and FS are empty) for
MCSubtargetInfo creation.
This patch should fix PR53956.
Reviewed by: labrinea
Differential Revision: https://reviews.llvm.org/D124319
(cherry picked from commit 4a31af88a26726f4662a2923618fe45977d09356)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A crash was seen in CastValueChecker due to a null pointer dereference.
The fix uses QualType::getAsString to avoid the null dereference
when a CXXRecordDecl cannot be obtained. A small reproducer is added,
and cast value notes LITs are updated for the new debug messages.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D127105
(cherry picked from commit c7fa4e8a8bc41e52cc49a27e0495d67d730fa167)
|
|
|
|
|
|
|
|
|
| |
Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.
(cherry picked from commit 30baa5d2a450d5e302d8cba3fc7a26a59d4b7ae1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were treating a move in the lambda capture as if it happened
within the body of the lambda, not within the function that defines the lambda.
This fixes the same bug as https://reviews.llvm.org/D119165 (which it appears
may have been abandoned by the author?) but does so more simply.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D126780
(cherry picked from commit 8b90b2539048a581052a4b0d7628ffba0cd582a9)
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/llvm/llvm-project/issues/53799.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D119680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/llvm/llvm-project/issues/55407.
Given configuration:
```
UseTab: Always
PointerAlignment: Right
AlignConsecutiveDeclarations: true
```
Before, the pointer was misaligned in this code:
```
void f() {
unsigned long long big;
char *ptr; // misaligned
int i;
}
```
That was due to the fact that when handling right-aligned pointers, the Spaces were changed but StartOfTokenColumn was not.
Also, a tab was used not only for indentation but for spacing too when using `UseTab: ForIndentation` config option:
```
void f() {
unsigned long long big;
char *ptr; // \t after char
int i;
}
```
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D125528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Factor in the TBAA of adjacent stores instead of just the head store
when merging stores into a memset. We were seeing GVN remove a load that
had a TBAA that matched the 2nd store because GVN determined it didn't
match the TBAA of the memset. The memset had the TBAA of only the first
store.
i.e. Loading the field pi_ of shared_count after memset to create an
array of shared_ptr
template<class T>
class shared_ptr {
T *p;
shared_count refcount;
};
class shared_count {
sp_counted_base *pi_;
};
Differential Revision: https://reviews.llvm.org/D122205
(cherry picked from commit e02f4976acbf086904bf3903348603cc0f04e6ad)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the choice between the instruction selection of ISD::FABS was
decided at the point of setting the MIPS target lowering operation choice
either `Custom` lowering or `Legal`. This lead to instruction selection
failures as functions could be marked as having no NaNs.
Changing the lowering to always be `Custom` and directly handling the
the cases where MIPS selects the instructions for ISD::FABS resolves
this crash.
Thanks to kray for reporting the issue and to Simon Atanasyan for producing
the reduced test case.
This resolves PR/53722.
Differential Revision: https://reviews.llvm.org/D124651
(cherry picked from commit 938ed8ae99f92c19cfb92b76a7e20a72409df84a)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit dd5991cc modified the aliasing checks here to allow transforming
a memcpy where the source and destination point into the same object.
However, the change accidentally made the code skip the alias check for
other operations in the loop.
Instead of completely skipping the alias check, just skip the check for
whether the memcpy aliases itself.
Differential Revision: https://reviews.llvm.org/D126486
(cherry picked from commit abdf0da8009f272f6c3d6398cf63f9f0a8257637)
|
|
|
|
|
|
|
|
|
| |
The MVE shuffle costing for VREV instructions was making incorrect
assumptions as to legalized vector types remaining as vectors. Add a
quick check to ensure they are indeed vectors before attempting to get
the number of elements.
(cherry picked from commit 53be6ab25cb97338384b9a73a4eef47cf3b89f3b)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without the change llvm build fails on this week's gcc-13 snapshot as:
[ 91%] Building CXX object unittests/Support/CMakeFiles/SupportTests.dir/Base64Test.cpp.o
In file included from llvm/unittests/Support/Base64Test.cpp:14:
llvm/include/llvm/Support/Base64.h: In function 'std::string llvm::encodeBase64(const InputBytes&)':
llvm/include/llvm/Support/Base64.h:29:5: error: 'uint32_t' was not declared in this scope
29 | uint32_t x = ((unsigned char)Bytes[i] << 16) |
| ^~~~~~~~
(cherry picked from commit 5e9be93566f39ee6cecd579401e453eccfbe81e5)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without the change llvm build fails on this week's gcc-13 snapshot as:
[ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o
In file included from llvm/lib/Support/Signals.cpp:14:
llvm/include/llvm/Support/Signals.h:119:8: error: variable or field 'CleanupOnSignal' declared void
119 | void CleanupOnSignal(uintptr_t Context);
| ^~~~~~~~~~~~~~~
(cherry picked from commit ff1681ddb303223973653f7f5f3f3435b48a1983)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
(cherry picked from commit 18efa420da5fa065d88ba451cdcdbd950a2090c1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the
call to `getImmediateExpansionRange().getBegin()` with
`getImmediateMacroCallerLoc()`, which has similar but subtly different
behaviour.
The consequence is that NOLINTs cannot suppress diagnostics when they are
attached to a token that came from a macro **argument**, rather than elsewhere
in the macro expansion.
Revert to pre-patch behaviour and add test cases to cover this issue.
Differential Revision: https://reviews.llvm.org/D126138
(cherry picked from commit 9ff4f2dfea632d63e3a57a88a2faa634aae5c772)
|
|
|
|
|
|
|
| |
The code was only checking for memory side-effects, but not for
divergence side-effects. Replace this with a generic check.
(cherry picked from commit 2e101cca690645d63ae4de1eb7b0e11d322448fd)
|
|
|
|
|
|
| |
Test both the case with and without willreturn attribute.
(cherry picked from commit 1f1de06165bb39f66049cdc942151fc6ed193123)
|
|
|
|
|
|
|
|
| |
Even though the comment description is ".unroll_inner.iv < NumIterations", the code emitted a BO_LE ('<=') operator for the inner loop that is to be unrolled. This lead to one additional copy of the body code in a partially unrolled. It only manifests when the unrolled loop is consumed by another loop-associated construct. Fix by using the BO_LT operator instead.
The condition for the outer loop and the corresponding code for tiling correctly used BO_LT already.
Fixes #55236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__nvvm_get_smem_pointer`
The change fixes https://github.com/llvm/llvm-project/issues/54609 (the second reported issue) by eliminating a compilation error occurring only on Windows while trying to compile any CUDA source file by clang (-x cuda).
[Repro]
clang -x cuda <any_cu_source>
[Error]
__clang_cuda_runtime_wrapper.h:473:
__clang_cuda_intrinsics.h(517,19): error GC871EEFB: unknown type name 'uint32_t'; did you mean 'cuuint32_t'?
__device__ inline uint32_t __nvvm_get_smem_pointer(void *__ptr) {
^
C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.6/include\cuda.h:57:26: note: 'cuuint32_t' declared here
typedef unsigned __int32 cuuint32_t;
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D122897
(cherry picked from commit c23147106f7efc4b5e29c47a08951116b4d994ac)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take the following as an example
struct z {
z (*p)();
};
z f();
When we attempt to get the LLVM type of f, we recurse into z. z itself
has a function pointer with the same type as f. Given the recursion,
Clang simply treats z::p as a pointer to an empty struct `{}*`. The
LLVM type of f is as expected. So we have two different potential
LLVM types for a given Clang type. If we store one of those into the
cache, when we access the cache with a different context (e.g. we
are/aren't recursing on z) we may get an incorrect result. There is some
attempt to clear the cache in these cases, but it doesn't seem to handle
all cases.
This change makes it so we only use the cache when we are not in any
sort of function context, i.e. `noRecordsBeingLaidOut() &&
FunctionsBeingProcessed.empty()`, which are the cases where we may
decide to choose a different LLVM type for a given Clang type. LLVM
types for builtin types are never recursive so they're always ok.
This allows us to clear the type cache less often (as seen with the
removal of one of the calls to `TypeCache.clear()`). We
still need to clear it when we use a placeholder type then replace it
later with the final type and other dependent types need to be
recalculated.
I've added a check that the cached type matches what we compute. It
triggered in this test case without the fix. It's currently not
check-clang clean so it's not on by default for something like expensive
checks builds.
This change uncovered another issue where the LLVM types for an argument
and its local temporary don't match. For example in type-cache-3, when
expanding z::dc's argument into a temporary alloca, we ConvertType() the
type of z::p which is `void ({}*)*`, which doesn't match the alloca GEP
type of `{}*`.
No noticeable compile time changes:
https://llvm-compile-time-tracker.com/compare.php?from=3918dd6b8acf8c5886b9921138312d1c638b2937&to=50bdec9836ed40e38ece0657f3058e730adffc4c&stat=instructions
Fixes #53465.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D118744
(cherry picked from commit 45084eab5e63550bf2fdbf325d8fa5498263130d)
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements avr-gcc's calling convention:
https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D120720
(cherry picked from commit 51585aa240de6ef07979345de5406483d7393b7b)
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes bug 55463, similar to D78668. This is a temporary fix since
we will switch to post-isel CTR loop determination in the future.
Reviewed By: dim, shchenz
Differential Revision: https://reviews.llvm.org/D125746
(cherry picked from commit d9d15af7873fe16d7a0dde4def30f40fa9901777)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a continuation of https://reviews.llvm.org/D123353.
Not only kernels in anonymous namespace, but also template
kernels with template arguments in anonymous namespace
need to be externalized.
To be more generic, this patch checks the linkage of a kernel
assuming the kernel does not have __global__ attribute. If
the linkage is internal then clang will externalize it.
This patch also fixes the postfix for externalized symbol
since nvptx does not allow '.' in symbol name.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D124189
Fixes: https://github.com/llvm/llvm-project/issues/54560
(cherry picked from commit 04fb81674ed7981397ffe70fe6a07b7168f6fe2f)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kernels in anonymous name space needs to have unique name
to avoid duplicate symbols.
Fixes: https://github.com/llvm/llvm-project/issues/54560
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D123353
(cherry picked from commit 4ea1d435099f992cc16127619b0feb64e070630d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In post-commit feedback on D104830 Jessica Clarke pointed out that
unconditionally adding __va_list to the std namespace caused namespace
debug info to be emitted in C, which is not only inappropriate but
turned out to confuse the dtrace tool. Therefore, move __va_list back
to std only in C++ so that the correct debug info is generated. We
also considered moving __va_list to the top level unconditionally
but this would contradict the specification and be visible to AST
matchers and such, so make it conditional on the language mode.
To avoid breaking name mangling for __va_list, teach the Itanium
name mangler to always mangle it as if it were in the std namespace
when targeting ARM architectures. This logic is not needed for the
Microsoft name mangler because Microsoft platforms define va_list as
a typedef of char *.
Depends on D116773
Differential Revision: https://reviews.llvm.org/D116774
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ItaniumMangleContextImpl. NFCI.
In an upcoming change we are going to need to access mangler state
from the getEffectiveDeclContext() function. Therefore, make it a
member function of ItaniumMangleContextImpl. Any callers that are
not currently members of ItaniumMangleContextImpl or CXXNameMangler
are made members of one or the other depending on where they are
called from.
Differential Revision: https://reviews.llvm.org/D116773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec
contexts. It doesn't do this consistently, but there is no need for
it to do it at all. getEffectiveDeclContext never returns a linkage
spec, as it either recurses, uses getRedeclContext (which itself
removes the specs), or gets the decl context of non-namespace entities.
This patch removes the function and all calls to it. For safety I add
a couple of asserts to make sure we never get them.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparing for module mangling changes I noticed some issues with
the way we check for std::basic_string instantiations and friends.
*) there's a single routine for std::basic_{i,o,io}stream but it is
templatized on the length of the name. Really? just use a
StringRef, rather than clone the entire routine just for
'basic_iostream'.
*) We have a helper routine to check for char type, and call it from
several places. But given all the instantiations are of the form
TPL<char, Other<char> ...> we could just check the first arg is char
and the later templated args are instantiating that same type. A
simpler type comparison.
*) Because basic_string has a third allocator parameter, it is open
coded, which I found a little confusing. But otherwise it's exactly
the same pattern as the iostream ones. Just tell that checker about
whether there's an expected allocator argument.[*]
*) We may as well return in each block of mangleStandardSubstitution
once we determine it is not one of the entities of interest -- it
certainly cannot be one of the other kinds of entities.
FWIW this shaves about 500 bytes off the executable.
[*] I suppose we could also have this routine a tri-value, with one to
indicat 'it is this name, but it's not the one you're looking for', to
avoid later calls trying different names?
Reviewd By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119333
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'call' (long call) instruction is available on avr3 and above,
and devices in avr2 and avr25 should use the 'rcall' (short call)
instruction for function calls.
Reviewed By: aykevl, dylanmckay
Differential Revision: https://reviews.llvm.org/D121539
(cherry picked from commit 45638931fb7c7a1b9c850e47601541b398868538)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An i8 argument should only cost 1 byte on the stack. This is
compatible with avr-gcc.
There are also more test cases (of calling convention) are added.
Reviewed By: aykevl, dylanmckay
Differential Revision: https://reviews.llvm.org/D121767
(cherry picked from commit 3fd9a320da8adbefa47071f70667d641f7dd26f2)
|
|
|
|
|
|
|
|
|
|
|
| |
Properly handle the case where only the second operand of e.g. an MVC
instruction uses a fixup for the displacement.
Reviewed By: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D125982
(cherry picked from commit e547b04d5b2c20bb5d14e49a86837c77573b267a)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
install locale fileset on AIX OS.
Summary:
1. there are 23 test cases which do not run because of locale fileset not install, after the locale installed, these test cases will be run and fail. "LIBCXX-AIX-FIXME" on the 23 test cases which remain to be investigated on AIX.
2.after installed the locale fileset ,
the test case
libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp pass
remove XFAIL: LIBCXX-AIX-FIXME from the file
Reviewers: David Tenty
Differential Revision: https://reviews.llvm.org/D124174
(cherry picked from commit bf4ddf18406c3e523c798ff7809f9e647580588c)
|
|
|
|
|
|
|
|
|
| |
The ranges concepts were already available in libc++13, so we shouldn't guard them with `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Fixes https://github.com/llvm/llvm-project/issues/54765
Differential Revision: https://reviews.llvm.org/D124011
(cherry picked from commit b177a90ce7b590dfce6479142f46fd1b9554a3b3)
|
|
|
|
|
|
| |
Similar to D123750 for AArch64.
(cherry picked from commit b483ce12281e31311efacf0047f95767517dcde9)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NamedDecl::getIdentifier can return a nullptr when
DeclarationName::isIdentifier is false, which leads to a null pointer
dereference when TypePrinter::printTemplateId calls ->getName().
NamedDecl::getName does the same thing in the successful case and
returns an empty string in the failure case.
This crash affects the llvm 14 packages on llvm.org.
(cherry picked from commit 225b91e6cbba31ff1ce787a152a67977d08fdcab)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes in D122444 caused OpenMP programs built with the
LLVM_ENABLE_RUNTIMES options to stop finding the libraries. We generally
expect to link against the libraries associated with the clang
installation itself but we no longer implicitly included that directory.
This patch adds in the include path of the clang installations library
to ensure we can find them.
Reviewed By: jdoerfert, MaskRay
Differential Revision: https://reviews.llvm.org/D122592
(cherry picked from commit fceea4e11028f4bfbafbd6893ddeb319420107d9)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to D119787 for PPC64.
A hidden undefined weak may change its binding to local before some
`isUndefinedWeak` code, so some `isUndefinedWeak` code needs to be changed to
`isUndefined`. The undefined non-weak case has been errored, so just using
`isUndefined` is fine.
The Linux kernel recently has a usage that a branch from 0xffff800008491ee0
references a hidden undefined weak symbol `vfio_group_set_kvm`.
It relies on the behavior that a branch to undefined weak resolving to the next
instruction, otherwise it'd see spurious relocation out of range errors.
Fixes https://github.com/ClangBuiltLinux/linux/issues/1624
Differential Revision: https://reviews.llvm.org/D123750
(cherry picked from commit 02eab52866775f1476028129d1b114235fddc127)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is used by a few projects like keepassxc and mumble.
Also see https://bugzilla.redhat.com/show_bug.cgi?id=2070813 that Fedora gcc has
an (unneeded) gcc12-no-add-needed.patch which adds --no-add-needed, although
--[no-]add-needed has been deprecated in GNU ld since 2009. Adding this has low
costs and makes several folks happy.
This basically restores 8f13bef575c97db4d6c146c3bb647ac9e73a9248.
Fixes https://github.com/llvm/llvm-project/issues/54756
(cherry picked from commit c29c19cb5327624dd31fcb776f8fbe66ca1011bb)
|
|
|
|
|
|
|
|
|
|
| |
Merging multiple legacy profiles (produced by instrumentation BOLT) can
easily reach GiBs. Let merge-fdata compact the profiles during merge to
significantly reduce space usage.
Differential Revision: https://reviews.llvm.org/D123513
(cherry picked from commit 7d7771f34d14e0108adf02a6fd0b33943afae3da)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case of placement new, if we do not know the alignment of the
operand, we can't assume it has the preferred alignment. It might be
e.g. a pointer to a struct member which follows ABI alignment rules.
This makes UBSAN no longer report "constructor call on misaligned
address" when constructing a double into a struct field of type double
on i686. The psABI specifies an alignment of 4 bytes, but the preferred
alignment used by Clang is 8 bytes.
We now use ABI alignment for allocating new as well, as the preferred
alignment should be used for over-aligning e.g. local variables, which
isn't relevant for ABI code dealing with operator new. AFAICT there
wouldn't be problems either way though.
Fixes #54845.
Differential Revision: https://reviews.llvm.org/D124736
(cherry picked from commit 93a8225da1f983cccb3e4b5e762369121aaa7dd5)
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D125454
(cherry picked from commit 791e0d1bc85d1963abddb96cadcdf201c43a029f)
|
|
|
|
|
|
|
|
|
|
| |
When GlobalISel fails, we need to report the error, and we need to set
the FailedISel property. We skipped those steps if stack protector
insertion failed, which led to a very strange miscompile.
Differential Revision: https://reviews.llvm.org/D125584
(cherry picked from commit 96c2a0c9fff24803be14bfaa579e4f230763d3cc)
|
|
|
|
|
|
|
|
|
|
| |
Similar to D116843 for Gnu.cpp
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124356
(cherry picked from commit 3d7da810e4a6e1ade2c0d649f17f8aa820248765)
|
|
|
|
|
|
|
|
|
|
| |
Similar to D116843 for Gnu.cpp
Reviewed By: zhmu, MaskRay
Differential Revision: https://reviews.llvm.org/D124729
(cherry picked from commit a132e527f25164268e08ebc63b043bbce8a043ed)
|
|
|
|
|
|
| |
Make it match LLVM's new minimum requirement (after https://reviews.llvm.org/D114639).
(cherry picked from commit 4db89e23190d1d1590d88df08056d327e651c94c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure to also handle extended value types to avoid crashing.
Resulting integers greater than 64 bits are not optimized (i128 is not a
legal type), and vectorizing seems to result in libcalls instead of just
scalarization.
Other extended vector types like <10 x float> are however now handled and
should result in vectorized conversions.
Reviewed By: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D125881
(cherry picked from commit 4273e616e573f4854e9c659c2e6d8a31f3e3c595)
|
|
|
|
|
|
|
|
| |
was already a PACK op
Fixes #55050
(cherry picked from commit e8305c0b8f492272446d517e67d451f390d35dbe)
|