| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i32 __builtin_annotation(i32, string);
Applying it to i64 (e.g., long long) generates the following IR.
trunc i64 {{.*}} to i32
call i32 @llvm.annotation.i32
zext i32 {{.*}} to i64
The redundant truncation and extension make the result difficult to use.
This patch makes __builtin_annotation() generic.
type __builtin_annotation(type, string);
For the i64 example, it simplifies the generated IR to:
call i64 @llvm.annotation.i64
Patch by Xi Wang!
llvm-svn: 155764
|
|
|
|
|
|
|
|
|
|
|
|
| |
more aligned than the block header but also contains something
smaller than the block-header alignment but not exactly half
the difference between the large alignment and the header
alignment. Got that?
I'm really not sure what I was thinking with the buggy computation
here, but the fix is pretty obvious.
llvm-svn: 155662
|
|
|
|
|
|
|
|
|
| |
With -fno-math-errno (the default for Darwin) or -ffast-math these library
function can be marked readnone enabling more opportunities for CSE and other
optimizations.
rdar://11251464
llvm-svn: 155498
|
|
|
|
|
|
| |
-relaxed-aliasing
llvm-svn: 155430
|
|
|
|
|
|
|
|
|
| |
find forward declarations in the context that the actual definition
will occur.
rdar://11291658
llvm-svn: 155381
|
|
|
|
|
|
|
|
| |
provide the types directly.
This should fix PR12628
llvm-svn: 155342
|
|
|
|
|
|
| |
Unfortunately, these instructions have behavior that can't be modeled with shuffle vector.
llvm-svn: 154906
|
|
|
|
| |
llvm-svn: 154897
|
|
|
|
|
|
|
| |
EmitFinalDestCopy (and thus pass EmitAggregateCopy the correct alignment).
rdar://11220251
llvm-svn: 154883
|
|
|
|
| |
llvm-svn: 154851
|
|
|
|
|
|
| |
up to this yet.
llvm-svn: 154835
|
|
|
|
| |
llvm-svn: 154789
|
|
|
|
|
|
| |
builtin_shufflevector instead of specific builtins. Old builtins will be removed from llvm now that vpermq/vpermpd are supported by shuffle lowering code.
llvm-svn: 154777
|
|
|
|
| |
llvm-svn: 154767
|
|
|
|
| |
llvm-svn: 154666
|
|
|
|
|
|
| |
GNU __atomic builtins.
llvm-svn: 154659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.
Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.
With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.
llvm-svn: 154640
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.
We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.
llvm-svn: 154579
|
|
|
|
|
|
|
|
|
| |
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
|
|
|
|
|
|
|
| |
of an uninitialized Stmt* in serialization of __atomic_init and add a test of
atomics serialization.
llvm-svn: 154448
|
|
|
|
|
|
| |
PR9796
llvm-svn: 154422
|
|
|
|
|
|
|
|
|
| |
and emit a relatively empty block for a plain break statement. This
enables us to track where we went through a switch.
PR9796 & rdar://11215207
llvm-svn: 154420
|
|
|
|
|
|
| |
as a vector actually usable. Patch by David Neto. PR12465.
llvm-svn: 154128
|
|
|
|
|
|
| |
Patch by Jack Carter. Testcase cleanup by me.
llvm-svn: 153921
|
|
|
|
|
|
| |
parentheses around uses of vector macro arguments.
llvm-svn: 153732
|
|
|
|
| |
llvm-svn: 153726
|
|
|
|
| |
llvm-svn: 153724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).
Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>
llvm-svn: 153710
|
|
|
|
| |
llvm-svn: 153670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM intrinsics for.
I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt. It's currently here:
http://people.freebsd.org/~theraven/atomic.c
It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...
llvm-svn: 153666
|
|
|
|
|
|
| |
Patch by Jack Carter.
llvm-svn: 153530
|
|
|
|
| |
llvm-svn: 153460
|
|
|
|
| |
llvm-svn: 153447
|
|
|
|
|
|
| |
Thanks to NAKAMURA Takumi for finding it!
llvm-svn: 153383
|
|
|
|
|
|
|
|
|
|
| |
metadata in clang for booleans and".
For i686 targets (eg. cygwin), I saw "Range must not be empty!" in verifier.
It produces (i32)[0x80000000:0x80000000) from (uint64_t)[0xFFFFFFFF80000000ULL:0x0000000080000000ULL), for signed i32 on MDNode::Range.
llvm-svn: 153382
|
|
|
|
|
|
| |
c++ enums.
llvm-svn: 153360
|
|
|
|
| |
llvm-svn: 153292
|
|
|
|
| |
llvm-svn: 153291
|
|
|
|
|
|
|
| |
cast the value to x86_mmx. This gives the ASM string the correct call signature.
<rdar://problem/10919182>
llvm-svn: 153290
|
|
|
|
| |
llvm-svn: 153289
|
|
|
|
|
|
| |
associated with vector element lvalues. Patch by Kevin Schoedel (with some minor modifications by me).
llvm-svn: 153285
|
|
|
|
|
|
| |
aren't supported at the moment. PR12040.
llvm-svn: 152891
|
|
|
|
|
|
| |
storage class, the asm name doesn't specify a register. PR12244.
llvm-svn: 152873
|
|
|
|
|
|
|
| |
the behavior of gcc with respect to the -fno-inline and -fno-inline-functions
flags.
llvm-svn: 152861
|
|
|
|
|
|
| |
Patch by Silviu Baranga!
llvm-svn: 152788
|
|
|
|
|
|
|
|
|
|
|
| |
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
llvm-svn: 152754
|
|
|
|
|
|
| |
powerpc_types and add testing for the (long) double there.
llvm-svn: 152647
|
|
|
|
| |
llvm-svn: 152552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We do this when it is easy to determine that the backend will pass them on
the stack properly by itself.
Currently LLVM codegen is really bad in some cases with byval, for example, on
the test case here (which is derived from Sema code, which likes to pass
SourceLocations around)::
struct s47 { unsigned a; };
void f47(int,int,int,int,int,int,struct s47);
void test47(int a, struct s47 b) { f47(a, a, a, a, a, a, b); }
we used to emit code like this::
...
movl %esi, -8(%rbp)
movl -8(%rbp), %ecx
movl %ecx, (%rsp)
...
to handle moving the struct onto the stack, which is just appalling.
Now we generate::
movl %esi, (%rsp)
which seems better, no?
llvm-svn: 152462
|