From aa306c2cc1945b3e68c8cf2925e9b1197126d54c Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Sat, 23 Jan 2010 17:59:23 +0000 Subject: 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 --- lib/Target/README.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'lib/Target') diff --git a/lib/Target/README.txt b/lib/Target/README.txt index 080ea42dcc..6c6290a70a 100644 --- a/lib/Target/README.txt +++ b/lib/Target/README.txt @@ -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 -- cgit v1.2.3