It is quite common that the chip manufacturer have available handoptimized functions for many of the more common algorithsm - or at least the important inner loops of them.

With a DSP - or a processor with good DSP add-on capabilities - it really is important to optimize the data flow between normally multiple memory regions to allow a high level of concurrency. A compiler have a hard time to find all possible optimizations.

But the majority of DSP applications don't need screaming performance, in which case the user may play with the trade offs. Fast processor with easy-to-read code in C. Slower processor with hyper-optimized C code (or maybe "semi-sloppy" assember). Even slower processor with hyper-optimized assembler code.

It's basically business as usual. Decide the cost of the chip multiplied with number of sold units, or compute the expected costs for the developer. And sometimes add in the "green" perspective - # of W the unit will consume, wich may greatly affect the total lifetime cost for the end user.

Edit: Just remember one important factor. If you design something that only works because you overclock the chip 50% - what backup plans do you have if you find that you actually need yet 10% more speed? Having a 100MHz 1-clocker do the task at 60MHz means you have 67% extra boost available as spare. Making use of a low-end chip in a family that have big brothers means that you have the option to switch to a beefier model.

You, on the other hand, seems to have selected the high-risk route. No backup plan, besides the fact that you have already pushed the initial solution way past the datasheet limitations.