| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 62125
|
| |
|
|
| |
llvm-svn: 62118
|
| |
|
|
|
|
|
|
| |
words, do not force all DIEs into first, whatever it is, compile unit.
Note, multiple compile unit support is not well tested (it did not work correctly until now anyway.)
llvm-svn: 62116
|
| |
|
|
| |
llvm-svn: 62115
|
| |
|
|
|
|
| |
soon.
llvm-svn: 62114
|
| |
|
|
|
|
|
| |
back to 200; 400 seems to be too high, loses more than
it gains.
llvm-svn: 62107
|
| |
|
|
| |
llvm-svn: 62104
|
| |
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
| |
|
|
|
|
| |
( May be this info should be directly handled by the dwarf writer ? )
llvm-svn: 62096
|
| |
|
|
| |
llvm-svn: 62092
|
| |
|
|
|
|
| |
is not a good idea.
llvm-svn: 62090
|
| |
|
|
|
|
| |
There might be more dead code, but with llvm-gcc bootstrap broken on linux x86-64 it is had to test :-(
llvm-svn: 62088
|
| |
|
|
|
|
|
|
| |
register to a virtual register unless it requires an expensive cross class copy. That means we are only treating "expensive to copy" register dependency as physical register dependency.
Also future proof the scheduler to handle "normal" physical register dependencies. The code is not exercised yet.
llvm-svn: 62074
|
| |
|
|
| |
llvm-svn: 62073
|
| |
|
|
|
|
|
| |
llvm.memcpy/memset/memmove. This allows removal of some
hackish code from basicaa.
llvm-svn: 62071
|
| |
|
|
|
|
| |
not a random piece of it. No functionality change.
llvm-svn: 62066
|
| |
|
|
|
|
|
|
|
| |
compensation for turning off gcc's inliner. This gets
us closer to the amount of inlining we were getting before.
It is not a win on everything, of course, but seems to
gain overall.
llvm-svn: 62058
|
| |
|
|
|
|
|
|
| |
opcode on each delegation.
Instead the information is cached on construction and the cached flag used thereafter.
Introduced two predicates: isCall and isInvoke.
llvm-svn: 62055
|
| |
|
|
|
|
| |
not thrilled about 64-bit % in general, so rewrite to use * instead.
llvm-svn: 62047
|
| |
|
|
|
|
| |
We should treat vectors as atomic types, not like arrays.
llvm-svn: 62046
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
canonicalization transform based on duncan's comments:
1) improve the comment about %.
2) within our index loop make sure the offset stays
within the *type size*, instead of within the *abi size*.
This allows us to reason explicitly about landing in tail
padding and means that issues like non-zero offsets into
[0 x foo] types don't occur anymore.
llvm-svn: 62045
|
| |
|
|
| |
llvm-svn: 62039
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 62036
|
| |
|
|
| |
llvm-svn: 62024
|
| |
|
|
| |
llvm-svn: 62023
|
| |
|
|
| |
llvm-svn: 62022
|
| |
|
|
| |
llvm-svn: 62015
|
| |
|
|
| |
llvm-svn: 62005
|
| |
|
|
| |
llvm-svn: 61999
|
| |
|
|
| |
llvm-svn: 61997
|
| |
|
|
| |
llvm-svn: 61995
|
| |
|
|
| |
llvm-svn: 61991
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed this in the code compiled for a routine using std::map, which produced
this code:
%25 = tail call i32 @memcmp(i8* %24, i8* %23, i32 6) nounwind readonly
%.lobit.i = lshr i32 %25, 31 ; <i32> [#uses=1]
%tmp.i = trunc i32 %.lobit.i to i8 ; <i8> [#uses=1]
%toBool = icmp eq i8 %tmp.i, 0 ; <i1> [#uses=1]
br i1 %toBool, label %bb3, label %bb4
which compiled to:
call L_memcmp$stub
shrl $31, %eax
testb %al, %al
jne LBB1_11 ##
with this change, we compile it to:
call L_memcmp$stub
testl %eax, %eax
js LBB1_11
This triggers all the time in common code, with patters like this:
%169 = and i32 %ply, 1 ; <i32> [#uses=1]
%170 = trunc i32 %169 to i8 ; <i8> [#uses=1]
%toBool = icmp ne i8 %170, 0 ; <i1> [#uses=1]
%7 = lshr i32 %6, 24 ; <i32> [#uses=1]
%9 = trunc i32 %7 to i8 ; <i8> [#uses=1]
%10 = icmp ne i8 %9, 0 ; <i1> [#uses=1]
etc
llvm-svn: 61985
|
| |
|
|
| |
llvm-svn: 61984
|
| |
|
|
|
|
| |
jump threading can have bugs, who knew? ;-)
llvm-svn: 61983
|
| |
|
|
| |
llvm-svn: 61980
|
| |
|
|
|
|
| |
(which is constant time and cheap) before checking hasAllZeroIndices.
llvm-svn: 61976
|
| |
|
|
| |
llvm-svn: 61972
|
| |
|
|
|
|
|
| |
the same formatting as their corresponding SSE2 instructions, for
consistency.
llvm-svn: 61971
|
| |
|
|
| |
llvm-svn: 61969
|
| |
|
|
|
|
| |
the comment a little more verbose.
llvm-svn: 61959
|
| |
|
|
|
|
| |
Now Users request DwarfWriter through getAnalysisUsage() instead of creating an instance of DwarfWriter object directly.
llvm-svn: 61955
|
| |
|
|
| |
llvm-svn: 61950
|
| |
|
|
| |
llvm-svn: 61949
|
| |
|
|
| |
llvm-svn: 61948
|
| |
|
|
|
|
|
|
|
|
|
| |
functions that don't already have a (dynamic) alloca.
Dynamic allocas cause inefficient codegen and we shouldn't
propagate this (behavior follows gcc). Two existing tests
assumed such inlining would be done; they are hacked by
adding an alloca in the caller, preserving the point of
the tests.
llvm-svn: 61946
|
| |
|
|
|
|
| |
day when more linkage types will be handled.
llvm-svn: 61944
|
| |
|
|
|
|
|
|
| |
will get its preferred alignment. It has to be careful and cautiously assume
it will just get the ABI alignment. This prevents instcombine from rounding
up the alignment of a load/store without adjusting the alignment of the alloca.
llvm-svn: 61934
|
| |
|
|
|
|
|
| |
llvm-as: t.ll:2:39: function may not return opaque type
%"bwmoyl" = tail call coldcc opaque @g()
^
llvm-svn: 61933
|
| |
|
|
| |
llvm-svn: 61928
|