[bitc-dev] Bitc and Simd

Christopher Gilbreth cngilbreth at gmail.com
Sun Aug 15 11:58:29 PDT 2010

Some thoughts:

(1) Perhaps BitC could find a way to *prove* that function arguments are not
aliased. One could then specify

def f (x: by-ref uint32[16]) (y: by-ref uint32[16]) (z: by-ref uint32[16])
require no_overlap(x,y)
  // ... stuff using SIMD instructions involving x and y

and have a compile-time guarantee that calls to f do not alias x and y. This
seems to be just the kind of thing BitC is designed for.

(2) For re-interpreting arrays for SIMD use, there might be an alias keyword
(orthochronous mentioned this above) which guarantees that no extra storage
is used:

let alias x_simd = (array sse2_uint16x8_t) x in
  // SSE2 stuff involving x_simd[] ...

(The (array sse2_uint16x8_t) term is meant to be a cast, I don't mean to
suggest this should be the exact syntax.) There would have to be some sort
of guarantee that the size of the array x is appropriate in this case.

(3) Any particular SIMD unit seems to naturally define a set of types and
operations among them, just as a general-purpose CPU does. Importing a
module for that unit would then import a set of such types, some infix
operators for them, and some intrinsics. Operations not supported by the
SIMD unit would *not* be included among these, so that using the types only
with their natural operations defined in the module would guarantee that
data is never moved to the general cpu registers. E.g., if the SIMD unit did
not define less-than (<) there would be no < operator for those types. If
you wanted to do that comparison, you would have to perform a cast, which
tells the programmer that something "unnatural" is going on.


On Fri, Aug 13, 2010 at 11:59 PM, orthochronous <orthochronous at gmail.com>wrote:

> Just a couple of quick points here. I'll write a more detailled
> response to Shap in a while.
> On Fri, Aug 13, 2010 at 10:07 PM, Alex Burr <ajb44.geo at yahoo.com> wrote:
> > c) conversions between the underlying atomic types, such as signed to
> unsigned
> > etc. IMO, this would be covered if bitc allows the intrinsics to be
> overloaded,
> > so you
> > are allowed to define overloaded versions which do the conversion for
> you. then
> > you don't need
> > to keep two pointers to the same data with different types. (It is not
> obvious
> > from my skimming how
> >  much overloading by type bitc allows?)
> There's some interaction between overloading and type inference (which
> can clearly be avoided by requiring enough explicit type annotation to
> avoid type inference.)
> > Both c) and d) lead me to the conclusion that you want to reduce
> aliassing where
> > possible by keeping only one pointer to
> > a given piece of data, and doing any conversions on values rather than
> pointers.
> >
> > On the whole, I think that if you have a function taking two pointer
> arguments,
> > you don't want the compiler to assume
> > that they can be aliased, at least by default. That removes lots of
> > optimisations it could otherwise do. However, maybe
> >
> > this is the opposite to what you want in a systems programming language,
> where
> > you value  predictability over
> >
> > speed. (If that is the case, maybe my previous paragraph is wrong).
> It's more the case where you've written a "routine" which is designed
> to work with arrays you expect to be distinct: it's not the usual
> thought process in current languages that, unless there's a big
> warning in the documentation like C's memcpy, that you can't call this
> with identical arguments. (That's partly what C's type based aliasing
> is codifying.) The motivating concern, and I agree with it, is that
> you can have source code which, as written, looks like a correct
> algorithm but if the compiler assumes arguments can't be identical
> then to "detect/debug" the problem you have to mentally figure out
> what the compiler may have done. In C there's the restrict attribute
> that you can use to make this declaration explicitly. My problem
> arises purely from the decision that int* and SIMD_Vector<int>* (or
> array if C had those) are decided to be just as different types as two
> differently declared structs, whereas in writing algorithms they're
> different views of the same data you might take a different times.
> (More a case of not appreciating the full interaction between 2
> different features.)
> Regards,
> David Steven Tweed
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100815/9b7d6b52/attachment.html 

More information about the bitc-dev mailing list