It is an extraordinarily difficult problem to transform scalar code into vector instructions. The only way to get even passable output from a vectorizing compiler is to write the code as vectors to begin with, such as with cross-platform assembly tools like Orc.
And even then you'll often end up significantly worse off than if you wrote the assembly by hand.
A run of Intel's compiler on the C versions of our DSP functions resulted in a grand total of one vectorization, which was done terribly, too.
The problem is that you used C, which doesn't have any syntax to represent meta-information about the problem you're trying to solve. When you write out C code to, say, add a list of numbers, it's hard for the compiler to optimize that. But it's very easy for the compiler when you tell it "sum this list of numbers".
As I understand - and I may be mistaken - the problem is that it's very hard to make sure that the emitted code is correct in the presence of raw pointers à la C.
I am told that Fortran does better than C here; there is a reason it is still widely used in the scientific computing community, after all.
This is also part of the reasoning behind C99's new restrict keyword.
In many cases it can, but then you have to be sure that it keeps doing so. You can write test cases for that, but in many cases it's easier to verify by just using the instructions directly.
If you don't write the compiler, you have to make assumptions about when and how it can/will use those instructions, and often you assume wrong, particularly across compiler upgrades.
And even then you'll often end up significantly worse off than if you wrote the assembly by hand.
A run of Intel's compiler on the C versions of our DSP functions resulted in a grand total of one vectorization, which was done terribly, too.