mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-27 15:29:51 +00:00
add some notes, making posix-memalign be nocapture would be an easy improvement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94312 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
187361b056
commit
aa306c2cc1
@ -356,12 +356,36 @@ this construct.
|
|||||||
|
|
||||||
//===---------------------------------------------------------------------===//
|
//===---------------------------------------------------------------------===//
|
||||||
|
|
||||||
|
[LOOP RECOGNITION]
|
||||||
|
|
||||||
viterbi speeds up *significantly* if the various "history" related copy loops
|
viterbi speeds up *significantly* if the various "history" related copy loops
|
||||||
are turned into memcpy calls at the source level. We need a "loops to memcpy"
|
are turned into memcpy calls at the source level. We need a "loops to memcpy"
|
||||||
pass.
|
pass.
|
||||||
|
|
||||||
//===---------------------------------------------------------------------===//
|
//===---------------------------------------------------------------------===//
|
||||||
|
|
||||||
|
[LOOP OPTIMIZATION]
|
||||||
|
|
||||||
|
SingleSource/Benchmarks/Misc/dt.c shows several interesting optimization
|
||||||
|
opportunities in its double_array_divs_variable function: it needs loop
|
||||||
|
interchange, memory promotion (which LICM already does), vectorization and
|
||||||
|
variable trip count loop unrolling (since it has a constant trip count). ICC
|
||||||
|
apparently produces this very nice code with -ffast-math:
|
||||||
|
|
||||||
|
..B1.70: # Preds ..B1.70 ..B1.69
|
||||||
|
mulpd %xmm0, %xmm1 #108.2
|
||||||
|
mulpd %xmm0, %xmm1 #108.2
|
||||||
|
mulpd %xmm0, %xmm1 #108.2
|
||||||
|
mulpd %xmm0, %xmm1 #108.2
|
||||||
|
addl $8, %edx #
|
||||||
|
cmpl $131072, %edx #108.2
|
||||||
|
jb ..B1.70 # Prob 99% #108.2
|
||||||
|
|
||||||
|
It would be better to count down to zero, but this is a lot better than what we
|
||||||
|
do.
|
||||||
|
|
||||||
|
//===---------------------------------------------------------------------===//
|
||||||
|
|
||||||
Consider:
|
Consider:
|
||||||
|
|
||||||
typedef unsigned U32;
|
typedef unsigned U32;
|
||||||
@ -1218,9 +1242,16 @@ store->load.
|
|||||||
|
|
||||||
//===---------------------------------------------------------------------===//
|
//===---------------------------------------------------------------------===//
|
||||||
|
|
||||||
|
[ALIAS ANALYSIS]
|
||||||
|
|
||||||
Type based alias analysis:
|
Type based alias analysis:
|
||||||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
|
||||||
|
|
||||||
|
We should do better analysis of posix_memalign. At the least it should
|
||||||
|
no-capture its pointer argument, at best, we should know that the out-value
|
||||||
|
result doesn't point to anything (like malloc). One example of this is in
|
||||||
|
SingleSource/Benchmarks/Misc/dt.c
|
||||||
|
|
||||||
//===---------------------------------------------------------------------===//
|
//===---------------------------------------------------------------------===//
|
||||||
|
|
||||||
A/B get pinned to the stack because we turn an if/then into a select instead
|
A/B get pinned to the stack because we turn an if/then into a select instead
|
||||||
|
Loading…
Reference in New Issue
Block a user