| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 84000
|
| |
|
|
| |
llvm-svn: 83999
|
| |
|
|
| |
llvm-svn: 83998
|
| |
|
|
|
|
| |
for purposes other than inlining.
llvm-svn: 83997
|
| |
|
|
|
|
|
| |
this will increase the likelihood of common code getting sunk towards
the unwind.
llvm-svn: 83996
|
| |
|
|
|
|
|
|
| |
BasicBlocks, so that it doesn't blindly procede in the presence of
large individual BasicBlocks. This addresses a class of code-size
expansion problems.
llvm-svn: 83992
|
| |
|
|
|
|
|
| |
GlobalValue is destroyed. Function destruction still leaks machine code and
can crash on leaked stubs, but this is some progress.
llvm-svn: 83987
|
| |
|
|
|
|
| |
not mean "there is no debug info in this module". :)
llvm-svn: 83984
|
| |
|
|
|
|
| |
Patch by Johnny Chen.
llvm-svn: 83983
|
| |
|
|
| |
llvm-svn: 83982
|
| |
|
|
|
|
| |
right approach for custom metadata data in general. However, right now the only custom data user, "dbg", expects this behavior while FE is constructing llvm IR with debug info.
llvm-svn: 83977
|
| |
|
|
| |
llvm-svn: 83973
|
| |
|
|
| |
llvm-svn: 83960
|
| |
|
|
|
|
| |
modify through the pointer they're given.
llvm-svn: 83959
|
| |
|
|
| |
llvm-svn: 83950
|
| |
|
|
|
|
|
|
| |
pointer at bitcast uses of a malloc call.
It should continue scanning until the malloc call, and this patch fixes that.
llvm-svn: 83931
|
| |
|
|
| |
llvm-svn: 83922
|
| |
|
|
| |
llvm-svn: 83921
|
| |
|
|
| |
llvm-svn: 83917
|
| |
|
|
|
|
|
|
|
| |
before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb. Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.
llvm-svn: 83916
|
| |
|
|
|
|
| |
should have been a pointer to a reference.
llvm-svn: 83915
|
| |
|
|
| |
llvm-svn: 83908
|
| |
|
|
| |
llvm-svn: 83905
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now. Radar 7291928.
The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it. There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code. The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range. On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted. The second CPE had
been in range but the newly inserted entry pushed it too far away. Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range. Etc.
Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references. In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs. This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it. This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs. This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.
To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion. The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses. This is a very simple change to the code and should not cause
any significant degradation in the results.
llvm-svn: 83902
|
| |
|
|
| |
llvm-svn: 83897
|
| |
|
|
| |
llvm-svn: 83894
|
| |
|
|
| |
llvm-svn: 83874
|
| |
|
|
| |
llvm-svn: 83873
|
| |
|
|
| |
llvm-svn: 83872
|
| |
|
|
|
|
|
|
|
| |
bootstrap of FSF-style PPC, so there is some
reason to believe the original bug (which was
never analyzed) has been fixed, probably by
82266.
llvm-svn: 83871
|
| |
|
|
| |
llvm-svn: 83870
|
| |
|
|
|
|
| |
same Value without breaking things.
llvm-svn: 83861
|
| |
|
|
| |
llvm-svn: 83857
|
| |
|
|
|
|
|
|
|
| |
it to hold the address of an sret return value, for x86-64 ABI purposes.
Also, fix the test that was originally intended to test this to actually
test it, using FileCheck.
llvm-svn: 83853
|
| |
|
|
|
|
|
| |
compile time penalty on gnugo, the worst case in MultiSource, is down to
about 2.5% from 30%
llvm-svn: 83824
|
| |
|
|
| |
llvm-svn: 83823
|
| |
|
|
| |
llvm-svn: 83822
|
| |
|
|
| |
llvm-svn: 83821
|
| |
|
|
|
|
|
|
|
|
|
| |
it to visit instructions from the start of the function to the
end of the function in the first path. This greatly speeds up
some pathological cases (e.g. PR5150).
Try #3, this time with some unneeded debug info stuff removed
which was causing dead pointers to be added to the worklist.
llvm-svn: 83818
|
| |
|
|
| |
llvm-svn: 83817
|
| |
|
|
|
|
|
|
| |
it to visit instructions from the start of the function to the
end of the function in the first path. This greatly speeds up
some pathological cases (e.g. PR5150).
llvm-svn: 83814
|
| |
|
|
| |
llvm-svn: 83812
|
| |
|
|
| |
llvm-svn: 83811
|
| |
|
|
|
|
|
|
|
|
|
| |
into a shuffle even if it was used by another insertelement. If the
visitation order of instcombine was wrong, this would turn a chain of
insertelements into a chain of shufflevectors, which was quite painful.
Since CollectShuffleElements handles these cases, the code can just
be nuked.
llvm-svn: 83810
|
| |
|
|
|
|
| |
new testcase.
llvm-svn: 83799
|
| |
|
|
| |
llvm-svn: 83797
|
| |
|
|
| |
llvm-svn: 83795
|
| |
|
|
|
|
|
|
|
| |
input the the mul is a zext from bool, just that it is all zeros
other than the low bit. This fixes some phase ordering issues
that would cause us to miss some xforms in mul.ll when the worklist
is visited differently.
llvm-svn: 83794
|
| |
|
|
| |
llvm-svn: 83792
|
| |
|
|
| |
llvm-svn: 83791
|