6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-03-04 21:31:03 +00:00
Code Issues Projects Releases Wiki Activity

add some notes, making posix-memalign be nocapture would be an easy improvement.

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94312 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2010-01-23 17:59:23 +00:00
parent 187361b056
commit aa306c2cc1
1 changed files with 31 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
lib/Target/README.txt
View File

@ -356,12 +356,36 @@ this construct.
//===---------------------------------------------------------------------===//
[LOOP RECOGNITION]
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"
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:
typedef unsigned U32;
@ -1218,9 +1242,16 @@ store->load.
//===---------------------------------------------------------------------===//
[ALIAS ANALYSIS]
Type based alias analysis:
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