On Tue, Apr 17, 2012 at 12:22 PM, Jonathan S. Shapiro <[email protected]> wrote: >> >> It seems to me that the importance of this becomes less significant in the face of JIT and polymorphic-inline-caches, since the inlined inner loop will have both the list iteraction and the type specialized data handling. > > The shape information is what allows us to know that the same implementation of CONS can be used for all boxed types. It is the thing that tells us that we may have already done the JIT work.
If i understand correctly, this is trying to reuse the jit work for 'list of (opaque 4 byte data)'... reusing this for any 4 byte data (or possibly any smaller than 4 byte data). For small value types, don't we hope the jit inlines right into the list parametric contents? For example, sum-of-ints loop is hopefully JIT inlined as a single fragment distinct from a sum-of-floats loop. Insertion into a sorted-list-of-int we hope is JIT inlined right into the int comparisons, distinct from sorted-list-of-float.. This is the source of my comment that with deep JIT inlining (polymorphic inline cache style), we don't use the "shaped jit version" anyhow... because we inlined deeper. It seems like this could be valuable for larger more complicated parametric values, especially where the overhead of having the size not "exactly" match isn't a big deal. For example, if we have a bunch of parametric lists with 12-15 byte values, it seems like "list of (16 byte opaque data)" might service them all, though it would waste space on 12-byte-value-types. Alternatively, it might be viable to JIT one generic version of the code which is paramaterized by the opaque value size. As long as more frequently used call sites end up with deep-inlined versions that have a static value size (and inlined parametric handling), such as "insert-int-into-sorted-list", then the fact that the shared version is a little slower because of the size-paramater may not be a big deal. I wonder how MSFT-CIL and Mono-CIL deal with this for parametric type-instantiation and JIT.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
