| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
sense of
how the CodeGen machinery works.
llvm-svn: 44786
|
| |
|
|
|
|
| |
impact the value of fall-through choices.
llvm-svn: 44785
|
| |
|
|
| |
llvm-svn: 44775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
llvm-svn: 44769
|
| |
|
|
|
|
|
| |
_sabre_: it has a major problem: by the time ~Value is run, all of the "parts" of the derived classes have been destroyed
_sabre_: the vtable lives to fight another day
llvm-svn: 44760
|
| |
|
|
| |
llvm-svn: 44756
|
| |
|
|
|
|
| |
2007-11-19-InlineAsm.ll
llvm-svn: 44755
|
| |
|
|
| |
llvm-svn: 44747
|
| |
|
|
|
|
| |
knows the vector is not pow2
llvm-svn: 44740
|
| |
|
|
| |
llvm-svn: 44733
|
| |
|
|
| |
llvm-svn: 44728
|
| |
|
|
| |
llvm-svn: 44727
|
| |
|
|
|
|
| |
that LegalizeDAG does.
llvm-svn: 44726
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%f8 = type <8 x float>
define void @test_f8(%f8* %P, %f8* %Q, %f8* %S) {
%p = load %f8* %P ; <%f8> [#uses=1]
%q = load %f8* %Q ; <%f8> [#uses=1]
%R = add %f8 %p, %q ; <%f8> [#uses=1]
store %f8 %R, %f8* %S
ret void
}
into:
_test_f8:
movaps 16(%rdi), %xmm0
addps 16(%rsi), %xmm0
movaps (%rdi), %xmm1
addps (%rsi), %xmm1
movaps %xmm0, 16(%rdx)
movaps %xmm1, (%rdx)
ret
llvm-svn: 44725
|
| |
|
|
| |
llvm-svn: 44724
|
| |
|
|
| |
llvm-svn: 44723
|
| |
|
|
| |
llvm-svn: 44722
|
| |
|
|
| |
llvm-svn: 44720
|
| |
|
|
| |
llvm-svn: 44719
|
| |
|
|
| |
llvm-svn: 44718
|
| |
|
|
| |
llvm-svn: 44717
|
| |
|
|
| |
llvm-svn: 44716
|
| |
|
|
| |
llvm-svn: 44715
|
| |
|
|
|
|
| |
Leave it visibility hidden, but not in an anon namespace.
llvm-svn: 44714
|
| |
|
|
| |
llvm-svn: 44710
|
| |
|
|
| |
llvm-svn: 44707
|
| |
|
|
| |
llvm-svn: 44705
|
| |
|
|
|
|
|
| |
what 'Available' is, please add a comment near it and rename it
if appropriate.
llvm-svn: 44703
|
| |
|
|
|
|
|
| |
isTriviallyReMaterializable -> hasNoSideEffects
isReallyTriviallyReMaterializable -> isTriviallyReMaterializable
llvm-svn: 44702
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a while ago. We now produce:
_foo:
mflr r0
std r0, 16(r1)
ld r2, 16(r1)
std r2, 0(r3)
ld r0, 16(r1)
mtlr r0
blr
instead of:
_foo:
mflr r0
std r0, 16(r1)
lis r0, 0
ori r0, r0, 16
ldx r2, r1, r0
std r2, 0(r3)
ld r0, 16(r1)
mtlr r0
blr
for:
void foo(void **X) {
*X = __builtin_return_address(0);
}
on ppc64.
llvm-svn: 44701
|
| |
|
|
| |
llvm-svn: 44700
|
| |
|
|
|
|
|
| |
different places to mean different things. Document what the
one in PPCFunctionInfo means and when it is valid.
llvm-svn: 44699
|
| |
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071203/056043.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071203/056048.html
llvm-svn: 44696
|
| |
|
|
|
|
|
|
| |
some (disabled) debugging code
to make such problems easier to diagnose in the future, written by Duncan Sands.
llvm-svn: 44695
|
| |
|
|
| |
llvm-svn: 44694
|
| |
|
|
| |
llvm-svn: 44692
|
| |
|
|
| |
llvm-svn: 44691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_foo:
li r2, 0
LBB1_1: ; bb
li r5, 0
stw r5, 0(r3)
addi r2, r2, 1
addi r3, r3, 4
cmplw cr0, r2, r4
bne cr0, LBB1_1 ; bb
LBB1_2: ; return
blr
to:
_foo:
li r2, 0
li r5, 0
LBB1_1: ; bb
stw r5, 0(r3)
addi r2, r2, 1
addi r3, r3, 4
cmplw cr0, r2, r4
bne cr0, LBB1_1 ; bb
LBB1_2: ; return
blr
ZOMG!! :-)
Moar to come...
llvm-svn: 44687
|
| |
|
|
| |
llvm-svn: 44686
|
| |
|
|
| |
llvm-svn: 44676
|
| |
|
|
| |
llvm-svn: 44671
|
| |
|
|
|
|
| |
to a <8 x i16> or <16 x i8> vector.
llvm-svn: 44669
|
| |
|
|
|
|
| |
Simpler and safer.
llvm-svn: 44663
|
| |
|
|
|
|
| |
llcbeta.
llvm-svn: 44660
|
| |
|
|
|
|
|
| |
only disable it if we don't know it will be obviously profitable.
Still fixme, but less so. :)
llvm-svn: 44658
|
| |
|
|
|
|
| |
the X86 backend are needed before this should be enabled by default.
llvm-svn: 44657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_foo:
movl $12, %eax
andl 4(%esp), %eax
movl _array(%eax), %eax
ret
instead of:
_foo:
movl 4(%esp), %eax
shrl $2, %eax
andl $3, %eax
movl _array(,%eax,4), %eax
ret
As it turns out, this triggers all the time, in a wide variety of
situations, for example, I see diffs like this in various programs:
- movl 8(%eax), %eax
- shll $2, %eax
- andl $1020, %eax
- movl (%esi,%eax), %eax
+ movzbl 8(%eax), %eax
+ movl (%esi,%eax,4), %eax
- shll $2, %edx
- andl $1020, %edx
- movl (%edi,%edx), %edx
+ andl $255, %edx
+ movl (%edi,%edx,4), %edx
Unfortunately, I also see stuff like this, which can be fixed in the
X86 backend:
- andl $85, %ebx
- addl _bit_count(,%ebx,4), %ebp
+ shll $2, %ebx
+ andl $340, %ebx
+ addl _bit_count(%ebx), %ebp
llvm-svn: 44656
|
| |
|
|
| |
llvm-svn: 44655
|
| |
|
|
|
|
| |
SelectionDAGLegalize::ScalarizeVectorOp
llvm-svn: 44654
|
| |
|
|
|
|
| |
same.
llvm-svn: 44651
|