Without seeing the code, or insight into what language this is implemented in its tough to provide a problem-specific solution. You say method so that may exclude some solutions that would be applicable in certain languages.
From the way the solution is posed it seems that speed is of the essence but you are bound to incur some overhead by decomposing the loop, although (if you are using a compiled language) it may inline some things for you.
If you are using C, C++ or another language that has pointers I would consider decomposing the loops into appropriately named functions and pass along those variables that the loop requires.
Additionally, depending on how your computation is laid out in memory you may still retain the speed you have acquired if the appropriate pointers are passed as you should not incur any cache-misses that you did not already have. But keep in mind conditional branching as you progress.
If you are using another language, you may have success in applying some of Martin Fowler's teachings (http://martinfowler.com/articles/refactoring-pipelines.html, http://www.refactoring.com/catalog/splitLoop.html).
The split loop is an often used performance optimisation in data intensive applications. When you are accessing to separate arrays in the same loop you can get hit badly by the cache misses. That is, if the arrays are large enough you loose locality of reference and the cache fails to do the job. Put enough code here and every operation will not hit the cache and instead have to go back out to main memory.
By splitting loops up into small separate components that only act on one array you get significant performance increases. In rendering code I've seen up to an order of magnitude difference. This is particularly beneficial if it is primitive type based and less so if class reference or pointer based where you need an additional dereference off into a random memory location. This technique is also very similar to loop unravelling for performance gains (although something I doubt would ever appear in a refactoring/patterns/OO type book :)
The last suggestion is attempting to simplify your expression using logic or determining if there is some data-structure that would better suit your computation in the legibility aspect.