What happens to the Instructions already in pipeline when interrupt occurs ?

Although it may not be appropriate (in general) to expose super-low-level details of the pipelining to the programmer, in this particular case, your question can be posed to Arm too, as they have decided to spread the indirect signs of that relevance across a few pages and some diagrams, expounding the method of fixing the exact point of recognition. But even that act must have been motivated by the requirements of the application developers, in which case the question is suggestive (perhaps rightfully so; coming from an RTOS developer himself/herself) of a practice, of relying on such a behaviour, that should be avoided.

The document says:

To prevent a program error, application code that relies on immediate recognition of the interrupt must have the memory barrier instructions added.

What types of apps cannot do without such immediate recognition? Perhaps RTOS? Or drivers of some sensitive devices? Or tightly-packed, highly-efficient code sequences with CPSIE/D that overlap with interrupt processing, and such an overlap must be avoided?

This behaviour brings to mind MIPS' branch delay slot.

--

My guess: the decision to execute an additional instruction, before branching to the ISR, depends on the exact point in time when the cpu sees the interrupt (denoted as "CPU pipeline accept the request" in the diagrams) relative to the stage in which the CPSIE instruction is at that point. If it is 'late', then the pipeline must have already partially processed the subsequent instruction, and there is no harm in delaying the recognition of this asynchronous interrupt until after that additional instruction is retired.

Although it may not be appropriate (in general) to expose super-low-level details of the pipelining to the programmer, in this particular case, your question can be posed to Arm too, as they have decided to spread the indirect signs of that relevance across a few pages and some diagrams, expounding the method of fixing the exact point of recognition. But even that act must have been motivated by the requirements of the application developers, in which case the question is suggestive (perhaps rightfully so; coming from an RTOS developer himself/herself) of a practice, of relying on such a behaviour, that should be avoided.

The document says:

To prevent a program error, application code that relies on immediate recognition of the interrupt must have the memory barrier instructions added.

What types of apps cannot do without such immediate recognition? Perhaps RTOS? Or drivers of some sensitive devices? Or tightly-packed, highly-efficient code sequences with CPSIE/D that overlap with interrupt processing, and such an overlap must be avoided?

This behaviour brings to mind MIPS' branch delay slot.

--

My guess: the decision to execute an additional instruction, before branching to the ISR, depends on the exact point in time when the cpu sees the interrupt (denoted as "CPU pipeline accept the request" in the diagrams) relative to the stage in which the CPSIE instruction is at that point. If it is 'late', then the pipeline must have already partially processed the subsequent instruction, and there is no harm in delaying the recognition of this asynchronous interrupt until after that additional instruction is retired.