Re: Support for packed instructions?

"Stephan Ceram" <linuxkaffee@gmx.net> wrote in message
> Many modern compilers support packed instructions (also called SIMD).
> However, languages like ANSI-C do not allow to express the data
> parallelism explicitly. So, some compiler vendors provide intrinsic
> functions that can be manually added into the source code and force
> the compiler to generate packed instructions. However, the manual
> insertion of these intrinsic functions makes the code not more
> portable.
>
> Do you know of any compiler source-to-source optimizations that
> automatically analyse ANSI-C code, find opportunities for the
> utilization of packed instructions and finally add them to the source
> code that is passed in the next step to a compiler? If so, how do such
> approaches work in general?
>


the existence of said intrinsics is evidence of the difficulty of the
problem...


but, there is something that works:
one can add high-level types for things commonly done with arrays of floats,
such as vectors, quaternions, and matrices...


this way, vector, quat, and matrix ops can nicely benefit from the
availability of SIMD operations, and one can fall back to intrinsics or
scalar code if this is not supported.


another use is generating specialized code for specialized tasks, such as
large matrix multiplies or inversions, ...




so, this wont speed up all code (and not plain ANSI-C), but it works for
some code at least, and these are also many of the same cases that are
likely to be bogged down as well...


yeah, and there are ways to do these kinds of things without the ugly syntax
extensions used by some compiler efforts, for which I have little idea why
they have to create such syntactic horrors, but oh well...


like, we can create new abstract types and intrinsics or similar, and then
use headers which give them a cleaner API, no need to hack on bunches of new
keywords and special syntax and crap which resembles templates...

Return to the comp.compilers page.
Search the comp.compilers archives again.