On Sat, Aug 14, 2010 at 8:05 PM, Ben Kloosterman <[email protected]> wrote:
> >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 ? > The compiler *doesn't* convert it. Just as we have integral types that are register allocatable, we introduce SIMD types and corresponding operations. The main problem with this approach is the fact that no two vendors agree on the implementation of the SIMD unit. What I think I'm saying here is that the right way to think about the SIMD unit is that it's a heterogeneous coprocessor that shares a memory (at least if ARM didn't break it) with the primary processor. > 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. > This case arises only in a few intrinsics, and isn't that hard to teach the compiler as a special case. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
