>I've spent today trying to understand what the type inference is doing >from the 2008 tech report. As mentioned in my initial email, my view >(as a user of SIMD) is that you really want SIMD to be a way of >"processing" aggregate data of simpler rather than a set of completely >distinct types. (Apart from anything else, mechanisms that require you >to specify types suitable for SIMD right from the beginning of the >programming violate the rule that you should write code for simplicity >first and then optimize hot-spots.) As such, I think the only >significant requirements are > >1. An explicit mechanism for telling the type system that within a >given block of code, this entity is going to be "processed as" a SIMD >type. (That could be using the conventional type conversion syntax >providing it optimizes away.)
How will this look in the code and more importantly how does the compiler convert it ? Also note there are 2 distinct use cases here under the BitC and Simd discussion. 1. SIMD algorithms 2. Using the 128 and 256 bit registers as pseudo GP registers for general work , this is at least as common eg memcpy . This case does not use aggregate data and is not even SIMD but still important. While SIMD algorithms are not really limited by the conversion costs ( as they are based on a loop work on SIMD prepared data) , using it for general work is. The cheaper you can make the conversion from GP register to SSE ( or better yet move some of the GP work to SSE in the first place) the more general optimizations that can be made as this code tends to run often but not in huge loops. Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
