Firstly, if execution time for interrupt handler is longer than the interrupt period itself (1 uS in your case), then its bad design. Make sure that interrupt handler does not do anything thats not essential to be done in the handler itself. Other tasks should be relegated to your state machine, and most the timer ISR should do is set a state or a flag.
Secondly, if that still happens to be the constraint you want to deal with, then although the timer is configured to interrupt at a rate of every 1 microsecond, due to the latency in handling the previous such interrupt, you are going to miss out on the latest interrupt. There is no de facto mechanism that can/should stack up the interrupts from the same peripheral and service them later one after another, neither you can/should keep track of such events.