| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 112302
|
| |
|
|
| |
llvm-svn: 112300
|
| |
|
|
|
|
| |
adjacent operands at once, instead of just two at a time.
llvm-svn: 112299
|
| |
|
|
|
|
| |
Patch by Cameron Esfahani!
llvm-svn: 112297
|
| |
|
|
|
|
| |
more general simplify demanded bits logic.
llvm-svn: 112291
|
| |
|
|
|
|
|
|
| |
transformation collect all the addrecs with the same loop
add combine them at once rather than starting everything over
at the first chance.
llvm-svn: 112290
|
| |
|
|
| |
llvm-svn: 112289
|
| |
|
|
| |
llvm-svn: 112288
|
| |
|
|
| |
llvm-svn: 112287
|
| |
|
|
| |
llvm-svn: 112286
|
| |
|
|
|
|
|
| |
computation can be truncated if it is fed by a sext/zext that doesn't
have to be exactly equal to the truncation result type.
llvm-svn: 112285
|
| |
|
|
|
|
| |
to DenseMap.
llvm-svn: 112281
|
| |
|
|
| |
llvm-svn: 112280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by the SRoA "promote to large integer" code, eliminating
some type conversions like this:
%94 = zext i16 %93 to i32 ; <i32> [#uses=2]
%96 = lshr i32 %94, 8 ; <i32> [#uses=1]
%101 = trunc i32 %96 to i8 ; <i8> [#uses=1]
This also unblocks other xforms from happening, now clang is able to compile:
struct S { float A, B, C, D; };
float foo(struct S A) { return A.A + A.B+A.C+A.D; }
into:
_foo: ## @foo
## BB#0: ## %entry
pshufd $1, %xmm0, %xmm2
addss %xmm0, %xmm2
movdqa %xmm1, %xmm3
addss %xmm2, %xmm3
pshufd $1, %xmm1, %xmm0
addss %xmm3, %xmm0
ret
on x86-64, instead of:
_foo: ## @foo
## BB#0: ## %entry
movd %xmm0, %rax
shrq $32, %rax
movd %eax, %xmm2
addss %xmm0, %xmm2
movapd %xmm1, %xmm3
addss %xmm2, %xmm3
movd %xmm1, %rax
shrq $32, %rax
movd %eax, %xmm0
addss %xmm3, %xmm0
ret
This seems pretty close to optimal to me, at least without
using horizontal adds. This also triggers in lots of other
code, including SPEC.
llvm-svn: 112278
|
| |
|
|
|
|
|
| |
Update all the tests using those intrinsics and add support for
auto-upgrading bitcode files with the old versions of the intrinsics.
llvm-svn: 112271
|
| |
|
|
|
|
|
|
| |
condition previously. Update tests for this change.
This fixes PR5652.
llvm-svn: 112270
|
| |
|
|
|
|
|
| |
return to avoid needing two calls to test for equivalence, and sort
addrecs by their degree before examining their operands.
llvm-svn: 112267
|
| |
|
|
| |
llvm-svn: 112266
|
| |
|
|
| |
llvm-svn: 112265
|
| |
|
|
|
|
| |
guess a path that will work.
llvm-svn: 112264
|
| |
|
|
|
|
|
| |
value should be copied to the corresponding shadow reg as well.
Patch by Cameron Esfahani!
llvm-svn: 112262
|
| |
|
|
| |
llvm-svn: 112260
|
| |
|
|
| |
llvm-svn: 112259
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
implements parts of C++0x based on the draft standard. An old version of
the draft had a bug that makes std::pair<T1*, T2*>(something, 0) fail to
compile. This is because the template<class U, class V> pair(U&& x, V&& y)
constructor is selected, even though it later fails to implicitly convert
U and V to frist_type and second_type.
This has been fixed in n3090, but it seems that Microsoft is not going to
update msvc.
llvm-svn: 112257
|
| |
|
|
|
|
| |
to find miscompiles with the integrated assembler.
llvm-svn: 112250
|
| |
|
|
| |
llvm-svn: 112242
|
| |
|
|
|
|
| |
to try to re-use scavenged frame index reference registers. rdar://8277890
llvm-svn: 112241
|
| |
|
|
|
|
| |
byval parameter.
llvm-svn: 112238
|
| |
|
|
|
|
|
| |
virtual base registers handle this function, and more. A bit more cleanup
to do on the interface to eliminateFrameIndex() after this.
llvm-svn: 112237
|
| |
|
|
| |
llvm-svn: 112235
|
| |
|
|
| |
llvm-svn: 112234
|
| |
|
|
|
|
|
| |
by SRoA. This is part of rdar://7892780, but needs another xform to
expose this.
llvm-svn: 112232
|
| |
|
|
| |
llvm-svn: 112228
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is a vector to be a vector element extraction. This allows clang to
compile:
struct S { float A, B, C, D; };
float foo(struct S A) { return A.A + A.B+A.C+A.D; }
into:
_foo: ## @foo
## BB#0: ## %entry
movd %xmm0, %rax
shrq $32, %rax
movd %eax, %xmm2
addss %xmm0, %xmm2
movapd %xmm1, %xmm3
addss %xmm2, %xmm3
movd %xmm1, %rax
shrq $32, %rax
movd %eax, %xmm0
addss %xmm3, %xmm0
ret
instead of:
_foo: ## @foo
## BB#0: ## %entry
movd %xmm0, %rax
movd %eax, %xmm0
shrq $32, %rax
movd %eax, %xmm2
addss %xmm0, %xmm2
movd %xmm1, %rax
movd %eax, %xmm1
addss %xmm2, %xmm1
shrq $32, %rax
movd %eax, %xmm0
addss %xmm1, %xmm0
ret
... eliminating half of the horribleness.
llvm-svn: 112227
|
| |
|
|
| |
llvm-svn: 112225
|
| |
|
|
| |
llvm-svn: 112224
|
| |
|
|
| |
llvm-svn: 112222
|
| |
|
|
|
|
|
|
| |
still having a significant effect. It shouldn't be now that the pre-RA
virtual base reg stuff is in. Assuming that's valididated by the nightly
testers, we can simplify a lot of the PEI frame index code.
llvm-svn: 112220
|
| |
|
|
| |
llvm-svn: 112218
|
| |
|
|
| |
llvm-svn: 112216
|
| |
|
|
| |
llvm-svn: 112215
|
| |
|
|
| |
llvm-svn: 112213
|
| |
|
|
| |
llvm-svn: 112208
|
| |
|
|
|
|
| |
register, used for a value, is initialized after a dbg intrinsic is seen.
llvm-svn: 112207
|
| |
|
|
|
|
| |
unintentional).
llvm-svn: 112206
|
| |
|
|
|
|
| |
depends on some clang patches which are not yet upstream.
llvm-svn: 112204
|
| |
|
|
| |
llvm-svn: 112203
|
| |
|
|
| |
llvm-svn: 112202
|
| |
|
|
| |
llvm-svn: 112200
|
| |
|
|
|
|
| |
compiled with clang++.
llvm-svn: 112198
|