| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_nontemporal_store in headers
We can now use __builtin_nontemporal_store instead of target specific builtins for naturally aligned nontemporal stores which avoids the need for handling in CGBuiltin.cpp
The scalar integer nontemporal (unaligned) store builtins will have to wait as __builtin_nontemporal_store currently assumes natural alignment and doesn't accept the 'packed struct' trick that we use for normal unaligned load/stores.
The nontemporal loads require further backend support before we can safely convert them to __builtin_nontemporal_load
Differential Revision: http://reviews.llvm.org/D21272
llvm-svn: 272540
|
|
|
|
|
|
| |
directly in the header file instead of in CGBuiltin.cpp. Simplify the sse2 equivalents as well.
llvm-svn: 272246
|
|
|
|
|
|
| |
since empty argument list mean something else in C.
llvm-svn: 272244
|
|
|
|
|
|
|
|
| |
undefined behavior for signed integer overflow.
This is really only needed for addition, subtraction, and multiplication, but I did the bitwise ops too for overall consistency. Clang currently doesn't set NSW for signed vector operations so the undefined behavior shouldn't happen today.
llvm-svn: 271778
|
|
|
|
|
|
|
|
|
|
|
|
| |
f32/f64 to i32 with generic IR (clang)
The 'cvtt' truncation (round to zero) conversions can be safely represented as generic __builtin_convertvector (fptosi) calls instead of x86 intrinsics. We already do this (implicitly) for the scalar equivalents.
Note: I looked at updating _mm_cvttpd_epi32 as well but this still requires a lot more backend work to correctly lower (both for debug and optimized builds).
Differential Revision: http://reviews.llvm.org/D20859
llvm-svn: 271436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the gcc headers, intel intrinsics docs and msdn codegen the _mm_store1_pd (and its _mm_store_pd1 equivalent) should use an aligned pointer - the clang headers are the only implementation I can find that assume non-aligned stores (by storing with _mm_storeu_pd).
Additionally, according to the intel intrinsics docs and msdn codegen the _mm_store1_ps (_mm_store_ps1) requires a similarly aligned pointer.
This patch raises the alignment requirements to match the other implementations by calling _mm_store_ps/_mm_store_pd instead.
I've also added the missing _mm_store_pd1 intrinsic (which maps to _mm_store1_pd like _mm_store_ps1 does to _mm_store1_ps).
As a followup I'll update the llvm fast-isel tests to match this codegen.
Differential Revision: http://reviews.llvm.org/D20617
llvm-svn: 271218
|
|
|
|
|
|
|
|
| |
that will compile to a native unaligned store. Remove the builtins since they are no longer used.
Intrinsics will be removed from llvm in a future commit.
llvm-svn: 271214
|
|
|
|
|
|
| |
As discussed on http://reviews.llvm.org/D20684, move the unsigned integer vector types used for zero extension to make them available for general use.
llvm-svn: 271187
|
|
|
|
|
|
|
|
|
|
| |
Both the (V)CVTDQ2PD(Y) (i32 to f64) and (V)CVTPS2PD(Y) (f32 to f64) conversion instructions are lossless and can be safely represented as generic __builtin_convertvector calls instead of x86 intrinsics without affecting final codegen.
This patch removes the clang builtins and their use in the sse2/avx headers - a future patch will deal with removing the llvm intrinsics, but that will require a bit more work.
Differential Revision: http://reviews.llvm.org/D20528
llvm-svn: 270499
|
|
|
|
|
|
| |
defined as. Add similar typecasts for the fp types as well.
llvm-svn: 269632
|
|
|
|
|
|
|
|
|
|
| |
intrinsics in this file are documented now. The patches for the rest of the intrisics in this file will be send out later.
The doxygen comments are automatically generated based on Sony's intrinsics document.
I got an OK from Eric Christopher to commit doxygen comments without prior code review upstream. This patch was internally reviewed by Paul Robinson.
llvm-svn: 265844
|
|
|
|
|
|
| |
inline assembly to implement _mm_pause.
llvm-svn: 252712
|
|
|
|
|
|
| |
couple intrinsics that were supposed to operate on MMX registers. Otherwise we end up operating on GPRs. Throw in a test for _mm_mul_su32 while I was there.
llvm-svn: 252711
|
|
|
|
|
|
| |
robust against inputs that aren't already the right type.
llvm-svn: 252700
|
|
|
|
| |
llvm-svn: 252587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test that our intrinsics behave the same under -fsigned-char and
-funsigned-char.
This further testing uncovered that AVX-2 has a broken cmpgt for 8-bit
elements, and has for a long time. This is fixed in the same way as
SSE4 handles the case.
The other ISA extensions currently work correctly because they use
specific instruction intrinsics. As soon as they are rewritten in terms
of generic IR, they will need to add these special casts. I've added the
necessary testing to catch this however, so we shouldn't have to chase
it down again.
I considered changing the core typedef to be signed, but that seems like
a bad idea. Notably, it would be an ABI break if anyone is reaching into
the innards of the intrinsic headers and passing __v16qi on an API
boundary. I can't be completely confident that this wouldn't happen due
to a macro expanding in a lambda, etc., so it seems much better to leave
it alone. It also matches GCC's behavior exactly.
A fun side note is that for both GCC and Clang, -funsigned-char really
does change the semantics of __v16qi. To observe this, consider:
% cat x.cc
#include <smmintrin.h>
#include <iostream>
int main() {
__v16qi a = { 1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
__v16qi b = _mm_set1_epi8(-1);
std::cout << (int)(a / b)[0] << ", " << (int)(a / b)[1] << '\n';
}
% clang++ -o x x.cc && ./x
-1, 1
% clang++ -funsigned-char -o x x.cc && ./x
0, 1
However, while this may be surprising, both Clang and GCC agree.
Differential Revision: http://reviews.llvm.org/D13324
llvm-svn: 249097
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13015
llvm-svn: 248156
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13009
llvm-svn: 248150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added missing SSE/AVX 'undefined' intrinsics (PR24040):
_mm_undefined_pd, _mm_undefined_ps + _mm_undefined_si128
_mm256_undefined_pd, _mm256_undefined_ps + _mm256_undefined_si256
_mm512_undefined, _mm512_undefined_ps, _mm512_undefined_pd + _mm512_undefined_epi32
Added builtin intrinsicss:
__builtin_ia32_undef128, __builtin_ia32_undef256 + __builtin_ia32_undef512
Differential Revision: http://reviews.llvm.org/D12052
llvm-svn: 246083
|
|
|
|
| |
llvm-svn: 241065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__(("sse3")))) foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
llvm-svn: 239883
|
|
|
|
|
|
|
| |
This is a precursor to changing them to use the new target attribute
code.
llvm-svn: 239882
|
|
|
|
|
|
| |
and _mm_srli_si128. This matches Intel documentation and gcc.
llvm-svn: 229066
|
|
|
|
|
|
| |
header.
llvm-svn: 229065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
backend can handle.
Also removed unused builtins.
Original patch by Andrea Di Biagio!
Reviewers: craig.topper, nadav
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7199
llvm-svn: 228481
|
|
|
|
|
|
| |
Instead of using 'unavailable', use '__unavailable__'
llvm-svn: 228087
|
|
|
|
|
|
|
|
|
|
| |
intrinsic files.
This still lower to the same intrinsics as before.
This is preparation for bounds checking the immediate on the avx version of the builtin so we don't pass illegal immediates into the backend. Since SSE uses a smaller size immediate its not possible to bounds check when using a shared builtin. Rather than creating a clang specific builtin for the different immediate, I decided (after consulting with Chandler) that it was better to match gcc.
llvm-svn: 224879
|
|
|
|
|
|
|
|
|
|
|
| |
Full discourse at:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131104/092514.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-November/068124.html
Patch by Dimitry Andric and Alexey Dokuchaev!
llvm-svn: 195558
|
|
|
|
|
|
|
| |
This is in line with implementation of _mm_extract_pi16.
rdar://15250497
llvm-svn: 193187
|
|
|
|
|
|
|
|
|
|
| |
Fixes <rdar://problem/10679282>.
I'm not completely satisfied with this patch. Sprinkling "diagnostic ignored"
_Pragmas throughout this file is gross, but I couldn't suppress
it for the entire file.
llvm-svn: 192143
|
|
|
|
|
|
|
|
|
| |
While I'm here, also fix the alignment computation for the whole family of
intrinsics.
PR17298.
llvm-svn: 191243
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics should return the comparision result in the low bits and keep
the high bits of the first source operand.
When calling to builtin functions, the source operands are swapped and the high
bits of the second source operand are kept. To fix the issue, an extra
shufflevector is used.
rdar://14153896
llvm-svn: 184110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft's Source Annotation Language (SAL) defines a bunch of keywords
for annotating the inputs and outputs of functions. Empty definitions
for the keywords are provided by <stdlib.h> -> <crtdefs.h> -> <sal.h>.
This makes it basically impossible to include MSVC's stdlib.h and
Clang's *mmintrin.h headers at the same time if they have variables
named __in. As a workaround, I've renamed those variables.
This fixes the Modules/compiler_builtins.m test which was XFAILed,
presumably due to this conflict.
llvm-svn: 179860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several of the intrinsic headers were using plain non-reserved identifiers.
C++11 17.6.4.3.2 [global.names] p1 reservers names containing a double
begining with an underscore followed by an uppercase letter for any use.
I think I got them all, but open to being corrected. For the most part I
didn't bother updating function-like macro parameter names because I don't
believe they're subject to any such collission - though some function-like
macros already follow this convention (I didn't update them in part because
the churn was more significant as several function-like macros use the double
underscore prefixed version of the same name as a parameter in their
implementation)
llvm-svn: 172666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
goodness because it provides opportunites to cleanup things. For example,
uint64_t t1(__m128i vA)
{
uint64_t Alo;
_mm_storel_epi64((__m128i*)&Alo, vA);
return Alo;
}
was generating
movq %xmm0, -8(%rbp)
movq -8(%rbp), %rax
and now generates
movd %xmm0, %rax
rdar://11282581
llvm-svn: 155924
|
|
|
|
| |
llvm-svn: 149742
|
|
|
|
| |
llvm-svn: 149725
|
|
|
|
| |
llvm-svn: 143792
|
|
|
|
|
|
|
|
| |
r138769.
<rdar://problem/10230751>
llvm-svn: 141310
|
|
|
|
|
|
|
|
| |
alignment (which probably has little effect in practice, but better to get it right). Make the load in _mm_loadh_pi and _mm_loadl_pi a single LLVM IR instruction to make optimizing easier for CodeGen.
rdar://10054986
llvm-svn: 139874
|
|
|
|
| |
llvm-svn: 138769
|
|
|
|
| |
llvm-svn: 131278
|
|
|
|
|
|
| |
correct unaligned load.
llvm-svn: 131268
|
|
|
|
|
|
|
|
|
|
| |
(__m128){ p[0], p[1], p[2], p[3] }
which produces really bad code. This could be done in instcombine, but it's
probably better to do it in the front-end instead.
<rdar://problem/9424836>
llvm-svn: 131237
|
|
|
|
|
|
| |
bad assumptions about the alignment of the double* argument.
llvm-svn: 131052
|
|
|
|
|
|
| |
into user code which may warn about them with -pedantic. Patch by Jonathan Sauer!
llvm-svn: 130149
|
|
|
|
|
|
|
|
|
| |
take it!
I wasn't able to get __builtin_ia32_loaddqu to transform into an unaligned
load...I'll have to look into it further.
llvm-svn: 129427
|
|
|
|
| |
llvm-svn: 115301
|
|
|
|
|
|
|
| |
so it needs to be called from a macro, not a function. This is a necessary
but insufficient step towards fixing PR8221
llvm-svn: 115299
|
|
|
|
|
|
| |
gcc defines them.
llvm-svn: 112146
|