3 Commits

Include renames

Author	SHA1	Message	Date
Steve Checkoway	177e65a34c	Do gcc's job for it and do sane loop unrolling. The (now second) while loop was stalling the pipeline almost as often as it was doing useful work. When gcc tried to do loop unrolling (i.e. when I changed the condition to size >= 8), it produced 4 _identical_ copies of the loop, each of which had the same number of stalls (this is all with the G5, the G4 had one stall in the loop). By unrolling and doing the most basic of instruction scheduling, this produces the same amount of code as gcc does but with 1 stall in the big loop (0 for the G4) but the same number in the second loop which is executed at most 3 times. ... To keep gcc from unrolling the second loop, I'm using the bit masking condition which confuses the optimizer. Note that this behavior won't change unless we stop targeting any OS below 10.3.9 and move to a more recent version of gcc (whose behavior I haven't bothered to test).	2006-05-17 09:27:54 +00:00
Steve Checkoway	b912d61546	Following Wolfman's example, some comments so that maybe next time I look at this I won't see vec_ctf and think "capture the flag?"	2006-05-14 08:13:16 +00:00
Steve Checkoway	f39e79efed	The last of the changes, I hope.	2006-05-14 07:04:28 +00:00