| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Use the new parameter on Function::getIntrinsicID to identify cases where
a function is being called with an "llvm." name but it isn't actually an
intrinsic. In such cases generate an error.
llvm-svn: 36121
|
|
|
|
|
|
|
|
| |
Don't assert everytime an intrinsic name isn't recognized. Instead, make
the assert optional when callin getIntrinsicID(). This allows the assembler
to handle invalid intrinsic names gracefully.
llvm-svn: 36120
|
|
|
|
| |
llvm-svn: 36102
|
|
|
|
|
|
|
| |
Fix a div-by-zero bug noticed by APInt. This fixes:
test/Transforms/IndVarsSimplify/exit_value_tests.llx
llvm-svn: 36099
|
|
|
|
| |
llvm-svn: 36094
|
|
|
|
| |
llvm-svn: 36090
|
|
|
|
|
|
| |
Transforms/IndVarsSimplify/exit_value_tests.llx
llvm-svn: 36081
|
|
|
|
|
|
|
|
|
|
| |
from DomTree. A lot of code for
constructing ImmediateDominator is now folded into DomTree construction.
This is part of the ongoing work for PR217.
llvm-svn: 36063
|
|
|
|
| |
llvm-svn: 36047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if/then/else.
This sinks the two stores in this example into a single store in cond_next. In this
case, it allows elimination of the load as well:
store double 0.000000e+00, double* @s.3060
%tmp3 = fcmp ogt double %tmp1, 5.000000e-01 ; <i1> [#uses=1]
br i1 %tmp3, label %cond_true, label %cond_next
cond_true: ; preds = %entry
store double 1.000000e+00, double* @s.3060
br label %cond_next
cond_next: ; preds = %entry, %cond_true
%tmp6 = load double* @s.3060 ; <double> [#uses=1]
This implements Transforms/InstCombine/store-merge.ll:test2
llvm-svn: 36040
|
|
|
|
| |
llvm-svn: 36037
|
|
|
|
| |
llvm-svn: 36035
|
|
|
|
|
|
| |
in the long process that will be fixing PR 217.
llvm-svn: 36034
|
|
|
|
| |
llvm-svn: 36031
|
|
|
|
| |
llvm-svn: 36028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
define i32 @test(float %f) {
%tmp7 = insertelement <4 x float> undef, float %f, i32 0
%tmp17 = bitcast <4 x float> %tmp7 to <4 x i32>
%tmp19 = extractelement <4 x i32> %tmp17, i32 0
ret i32 %tmp19
}
into:
define i32 @test(float %f) {
%tmp19 = bitcast float %f to i32 ; <i32> [#uses=1]
ret i32 %tmp19
}
On PPC, this is the difference between:
_test:
mfspr r2, 256
oris r3, r2, 8192
mtspr 256, r3
stfs f1, -16(r1)
addi r3, r1, -16
addi r4, r1, -32
lvx v2, 0, r3
stvx v2, 0, r4
lwz r3, -32(r1)
mtspr 256, r2
blr
and:
_test:
stfs f1, -4(r1)
nop
nop
nop
lwz r3, -4(r1)
blr
llvm-svn: 36025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unsigned test(float f) {
return _mm_cvtsi128_si32( (__m128i) _mm_set_ss( f*f ));
}
into:
_test:
movss 4(%esp), %xmm0
mulss %xmm0, %xmm0
movd %xmm0, %eax
ret
instead of:
_test:
movss 4(%esp), %xmm0
mulss %xmm0, %xmm0
xorps %xmm1, %xmm1
movss %xmm0, %xmm1
movd %xmm1, %eax
ret
GCC gets:
_test:
subl $28, %esp
movss 32(%esp), %xmm0
mulss %xmm0, %xmm0
xorps %xmm1, %xmm1
movss %xmm0, %xmm1
movaps %xmm1, %xmm0
movd %xmm0, 12(%esp)
movl 12(%esp), %eax
addl $28, %esp
ret
llvm-svn: 36020
|
|
|
|
| |
llvm-svn: 36017
|
|
|
|
| |
llvm-svn: 36016
|
|
|
|
|
|
| |
some reason. :( Will investigate.
llvm-svn: 36011
|
|
|
|
| |
llvm-svn: 36002
|
|
|
|
| |
llvm-svn: 35998
|
|
|
|
| |
llvm-svn: 35996
|
|
|
|
|
|
| |
shouldn't. Also fix some "latent" bug on 64-bit platforms
llvm-svn: 35990
|
|
|
|
| |
llvm-svn: 35985
|
|
|
|
|
|
|
|
| |
printf("") -> noop. Still need to do the xforms for fprintf.
This implements Transforms/SimplifyLibCalls/Printf.ll
llvm-svn: 35984
|
|
|
|
|
|
| |
in order to clean up after simplifylibcalls.
llvm-svn: 35982
|
|
|
|
| |
llvm-svn: 35981
|
|
|
|
| |
llvm-svn: 35979
|
|
|
|
|
|
| |
Writing it twice in the same day was too much for me.
llvm-svn: 35978
|
|
|
|
| |
llvm-svn: 35977
|
|
|
|
| |
llvm-svn: 35975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out to do! :)
This fixes a problem where LSR would insert a bunch of code into each MBB
that uses a particular subexpression (e.g. IV+base+C). The problem is that
this code cannot be CSE'd back together if inserted into different blocks.
This patch changes LSR to attempt to insert a single copy of this code and
share it, allowing codegenprepare to duplicate the code if it can be sunk
into various addressing modes. On CodeGen/ARM/lsr-code-insertion.ll,
for example, this gives us code like:
add r8, r0, r5
str r6, [r8, #+4]
..
ble LBB1_4 @cond_next
LBB1_3: @cond_true
str r10, [r8, #+4]
LBB1_4: @cond_next
...
LBB1_5: @cond_true55
ldr r6, LCPI1_1
str r6, [r8, #+4]
instead of:
add r10, r0, r6
str r8, [r10, #+4]
...
ble LBB1_4 @cond_next
LBB1_3: @cond_true
add r8, r0, r6
str r10, [r8, #+4]
LBB1_4: @cond_next
...
LBB1_5: @cond_true55
add r8, r0, r6
ldr r10, LCPI1_1
str r10, [r8, #+4]
Besides being smaller and more efficient, this makes it immediately
obvious that it is profitable to predicate LBB1_3 now :)
llvm-svn: 35972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this fixes problems where codegenprepare would sink expressions into load/stores
that are not valid, and fixes cases where it would miss important valid ones.
This fixes several serious codesize and perf issues, particularly on targets
with complex addressing modes like arm and x86. For example, now we compile
CodeGen/X86/isel-sink.ll to:
_test:
movl 8(%esp), %eax
movl 4(%esp), %ecx
cmpl $1233, %eax
ja LBB1_2 #F
LBB1_1: #T
movl $4, (%ecx,%eax,4)
movl $141, %eax
ret
LBB1_2: #F
movl (%ecx,%eax,4), %eax
ret
instead of:
_test:
movl 8(%esp), %eax
leal (,%eax,4), %ecx
addl 4(%esp), %ecx
cmpl $1233, %eax
ja LBB1_2 #F
LBB1_1: #T
movl $4, (%ecx)
movl $141, %eax
ret
LBB1_2: #F
movl (%ecx), %eax
ret
llvm-svn: 35970
|
|
|
|
|
|
| |
represent a string in binary form by an APInt.
llvm-svn: 35968
|
|
|
|
| |
llvm-svn: 35967
|
|
|
|
| |
llvm-svn: 35966
|
|
|
|
| |
llvm-svn: 35965
|
|
|
|
| |
llvm-svn: 35963
|
|
|
|
| |
llvm-svn: 35962
|
|
|
|
| |
llvm-svn: 35960
|
|
|
|
|
|
| |
less huge code that needs to be cleaned up by sdisel.
llvm-svn: 35959
|
|
|
|
| |
llvm-svn: 35957
|
|
|
|
|
|
|
| |
linkage so we only end up with one of them in a program. These are, after
all overloaded and templatish in nature.
llvm-svn: 35956
|
|
|
|
|
|
|
|
| |
This can happen for intrinsics that are overloaded. In such cases it is
necessary to emit a function prototype before the body of the function
that calls the intrinsic and to ensure we don't emit it multiple times.
llvm-svn: 35954
|
|
|
|
| |
llvm-svn: 35951
|
|
|
|
| |
llvm-svn: 35950
|
|
|
|
|
|
| |
barf when CBE is run with a program that contains these intrinsics.
llvm-svn: 35946
|
|
|
|
|
|
| |
the size of the value, not just zext. Also, give better names to two BBs.
llvm-svn: 35945
|
|
|
|
|
|
|
|
| |
class supports. In the case of vectors, this means we often get the wrong
type (e.g. we get v4f32 instead of v8i16). Make sure to convert the vector
result to the right type. This fixes CodeGen/X86/2007-04-11-InlineAsmVectorResult.ll
llvm-svn: 35944
|