| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
These are implementation helper macros we shouldn't expose them to user code if we don't need to.
llvm-svn: 333064
|
|
|
|
|
|
|
|
| |
feeding it to set1.
Previously we negated the whole vector after splatting infinity. But its better to negate the infinity before splatting. This generates IR with the negate already folded with the infinity constant.
llvm-svn: 333062
|
|
|
|
|
|
| |
CGBuiltin.cpp. Just wrap a select builtin around them in the header file instead.
llvm-svn: 333061
|
|
|
|
|
|
|
|
|
|
| |
intrinsics into f16cintrin.h and remove __emmintrin_f16c.h
These were included in emmintrin.h to match Intel Intrinsics Guide documentation. But this is because icc is capable of emulating them on targets that don't support F16C using library calls. Clang/LLVM doesn't have this emulation support. So it makes more sense to include them in immintrin.h instead.
I've left a comment behind to hopefully deter someone from trying to move them again in the future.
llvm-svn: 333033
|
|
|
|
|
|
| |
CGBuiltin.cpp. Just wrap a select builtin around them in the header file instead.
llvm-svn: 333027
|
|
|
|
| |
llvm-svn: 333026
|
|
|
|
|
|
| |
in r333014.
llvm-svn: 333023
|
|
|
|
|
|
| |
I missed this in r333014
llvm-svn: 333020
|
|
|
|
|
|
|
|
|
|
|
|
| |
emmintrin.h. Move 256-bit f16c intrinsics back to f16cintrin.h
Intel documents the 128-bit versions as being in emmintrin.h and the 256-bit version as being in immintrin.h.
This patch makes a new __emmtrin_f16c.h to hold the 128-bit versions to be included from emmintrin.h. And makes the existing f16cintrin.h contain the 256-bit versions and include it from immintrin.h with an error if its included directly.
Differential Revision: https://reviews.llvm.org/D47174
llvm-svn: 333014
|
|
|
|
|
|
| |
without including wmmintrin.h
llvm-svn: 332929
|
|
|
|
|
|
|
|
|
|
|
|
| |
packed float conversion intrinsics.
I believe this is safe assuming default default FP environment. The conversion might be inexact, but it can never overflow the FP type so this shouldn't be undefined behavior for the uitofp/sitofp instructions.
We already do something similar for scalar conversions.
Differential Revision: https://reviews.llvm.org/D46863
llvm-svn: 332882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These look to be a couple things that weren't removed when we switched to target attribute.
The popcnt makes including just smmintrin.h also include popcntintrin.h. The popcnt file itself already contains target attrributes.
The prefetch ones are just wrappers around __builtin_prefetch which we have graceful fallbacks for in the backend if the exact instruction isn't available. So there's no reason to hide them. And it makes them available in functions that have the write target attribute but not a -march command line flag.
Reviewers: echristo, RKSimon, spatel, DavidKreitzer
Reviewed By: echristo
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47029
llvm-svn: 332830
|
|
|
|
|
|
|
|
| |
in IR instead.
Someday maybe we'll use selects for all the builtins.
llvm-svn: 332825
|
|
|
|
|
|
| |
introduced in r332266.
llvm-svn: 332738
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rsmith
Subscribers: sanjoy, cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D46993
llvm-svn: 332619
|
|
|
|
|
|
|
|
| |
the avx512 truncate builtins.
The masking doesn't work right in the backend for the ones that produce byte or word elements without avx512bw.
llvm-svn: 332322
|
|
|
|
|
|
|
|
|
|
| |
builtins.
As long as the destination type is a 256 or 128 bit vector with the same number of elements we can use __builtin_convertvector to directly generate trunc IR instruction which will be handled natively by the backend.
Differential Revision: https://reviews.llvm.org/D46742
llvm-svn: 332266
|
|
|
|
|
|
| |
_mm512_mask_cvtps_pd and _mm512_maskz_cvtps_pd.
llvm-svn: 332213
|
|
|
|
|
|
|
|
| |
If we're using default rounding mode we can let __builtin_convertvector to generate an fpextend. This matches 128 and 256 bit.
If we're using the version that takes an explicit rounding mode argument we would need to look at the immediate to see if its CUR_DIRECTION.
llvm-svn: 332210
|
|
|
|
|
|
|
|
|
|
| |
_mm_cvtu64_ss.
We can use direct C code for these that will use uitofp and insertelement instructions.
For the versions that take an explicit rounding mode we can't do this.
llvm-svn: 332203
|
|
|
|
| |
llvm-svn: 332108
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D46683
llvm-svn: 332091
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, RKSimon
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D46540
llvm-svn: 331962
|
|
|
|
|
|
|
|
|
|
| |
not use a 512-bit intermediate vector.
This is unnecessary for AVX512VL supporting CPUs like SKX. We can just emit a 128-bit masked load/store here no matter what. The backend will widen it to 512-bits on KNL CPUs.
Fixes the frontend portion of PR37386. Need to fix the backend to optimize the new sequences well.
llvm-svn: 331958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D46435
llvm-svn: 331743
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D46431
llvm-svn: 331740
|
|
|
|
|
|
|
|
| |
Without this we throw an error on the header file instead of the user code when the right features aren't enabled in clang.
Rename the other DEFAULT_FN_ATTRS defines to _Z for 512-bit since I used _Y for this case.
llvm-svn: 331682
|
|
|
|
|
|
|
|
| |
headers.
Some were too long and some were too short.
llvm-svn: 331559
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It reverts r331378 as it caused test failures
ThreadSanitizer-x86_64 :: Darwin/gcd-groups-destructor.mm
ThreadSanitizer-x86_64 :: Darwin/libcxx-shared-ptr-stress.mm
ThreadSanitizer-x86_64 :: Darwin/xpc-race.mm
Only clang part of the change is reverted, libc++ part remains as is because it
emits error less aggressively.
llvm-svn: 331392
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331378
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: spatel, craig.topper, RKSimon
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45984
llvm-svn: 331249
|
|
|
|
|
|
|
|
|
|
| |
intrinsics to match icc.
On AVX512F targets we'll produce an emulated sequence using 3 pmuludqs with shifts and adds. On AVX512DQ we'll use vpmulld.
Fixes PR37140.
llvm-svn: 330923
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D45827
llvm-svn: 330753
|
|
|
|
| |
llvm-svn: 330744
|
|
|
|
|
|
|
|
| |
guards in our intrinsic headers.
Most files used double underscore, but a few used single. This converges them all to double.
llvm-svn: 330743
|
|
|
|
|
|
| |
The unmasked versions already didn't have this restrction. I don't think gcc or icc limit these to 64-bit mode so we shouldn't either.
llvm-svn: 330681
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45254
llvm-svn: 330463
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D45780
llvm-svn: 330280
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45257
llvm-svn: 329993
|
|
|
|
|
|
|
|
|
|
|
|
| |
A previously missing intrinsic for an old instruction.
Reviewers: craig.topper, echristo
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45311
llvm-svn: 329937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The WBNOINVD instruction writes back all modified
cache lines in the processor’s internal cache to main memory
but does not invalidate (flush) the internal caches.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43817
llvm-svn: 329848
|
|
|
|
| |
llvm-svn: 329777
|
|
|
|
|
|
|
|
|
|
| |
intrinsic and a select.
This makes it consistent with the 128/256-bit functions.
Someday maybe we'll have all the masking moved to selects.
llvm-svn: 329775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
|
|
|
|
|
|
|
|
|
|
| |
- Fix instruction mappings/listings for various intrinsics
This patch was made by Craig Flores
Differential Revision: https://reviews.llvm.org/D41517
llvm-svn: 327090
|
|
|
|
| |
llvm-svn: 326807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The _get_ssp intrinsic can be used to retrieve the
shadow stack pointer, independent of the current arch -- in
contract with the rdsspd and the rdsspq intrinsics.
Also, this intrinsic returns zero on CPUs which don't
support CET. The rdssp[d|q] instruction is decoded as nop,
essentially just returning the input operand, which is zero.
Example result of compilation:
```
xorl %eax, %eax
movl %eax, %ecx
rdsspq %rcx # NOP when CET is not supported
movq %rcx, %rax # return zero
```
Reviewers: craig.topper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43814
llvm-svn: 326689
|
|
|
|
|
|
| |
sse/avx buiiltins and a select.
llvm-svn: 326039
|
|
|
|
|
|
| |
__builtin_ia32_permvarsi256_mask and use the avx2 unmasked versions and a select instead.
llvm-svn: 326022
|