That being said...how would one go about calculating exactly how many machine cycles
The point is that if you use defensive coding practices (in this case auto-reload) you do not need to calculate cycles.
If, indeed, you want to know a timing, set a bit at entry and reset it at exit, then use a scope. This method has the advantage over "cycle counting" that you can see the jitter caused by the decisions taken inside the ISR. If you do not have a scope, but use a chip with an unused timer or PCA, you can use that to count and read it in the ICE. Using e.g. Keils sim has one disadvantage which is that you do not have the real environment for taking the various routes the decisions inside the ISR will cause.

Counting cycles can be dangerous if you depend on the cycle count being small enough for something else to fumnction. A small change or upgrading the compiler can make the whole house of cards fall. I recall a case where I did something somewhere and something else fell apart. It turned out to be something "cycle count critical". There is no way you can avoid being cycle count sensitive, the point is to reduce that sensitivity.

Erik

If you want to see an example of a dramatically decision bound ISR have a look at the ISR for a hardware IIC