how pc is updated during execution of SWI and any simple instruction like mov R1,R15?

Imagine your 3-stage pipeline like this:

PC - FETCH - PC+4 -> DEC - PC+4 -> EXECUTE ||

Exceptions are generated (pended) at the end of each stage and taken at the end of EXECUTE. So an error in FETCH will take the value PC and carry it through to the end of the pipeline so it can be taken when the current instruction finishes.

An error or exception-causing instruction in decode (SVC et al.) will sample PC and carry it to EXECUTE but FETCH has incremented it by +4. For SVC this is good because it then automatically points at the instruction after SVC. For UNDEF exceptions you need to subtract 4 if you want to re-execute that instruction.

an error in EXECUTE (say a failed load or store) already has the PC incremented by +4 again, so data aborts the value sampled is PC+8. Hence the need to subtract before exception return.

EXECUTE can also not fail and in this case any instruction that reads R15 will see PC+8 because it's already incremented by +4 at FETCH and +4 in DECODE before EXECUTE. Hence you always see the PC 8 bytes ahead of the current instruction as a result of MOV Rx, PC.

LR_SVC will reflect PC+4 at exception handler but the most common case is to return to the next instruction. Therefore to see the PC value of the SVC instruction itself YOU have to subtract 4. The exception is taken at EXECUTE even though we pended it in DECODE, so while executing it we can either do one of two things; use PC+4 carries with the pended exception or just use the PC at EXECUTE and the core will subtract 4. Or any other method - how you route execution data around the pipeline is a problem for pipeline designers.

It doesn't REALLY matter since Cortex-A modern pipelines don't look like that. It's all fake to maintain compatibility with software that MUST reflect old behavior. Which is, again, a problem for pipeline designers.

as a software developer wondering why the PC is the value it is or why the LR_SVC value is the value it is, you just need to read the documentation and do what it tells you to expect.

Imagine your 3-stage pipeline like this:

PC - FETCH - PC+4 -> DEC - PC+4 -> EXECUTE ||

Exceptions are generated (pended) at the end of each stage and taken at the end of EXECUTE. So an error in FETCH will take the value PC and carry it through to the end of the pipeline so it can be taken when the current instruction finishes.

An error or exception-causing instruction in decode (SVC et al.) will sample PC and carry it to EXECUTE but FETCH has incremented it by +4. For SVC this is good because it then automatically points at the instruction after SVC. For UNDEF exceptions you need to subtract 4 if you want to re-execute that instruction.

an error in EXECUTE (say a failed load or store) already has the PC incremented by +4 again, so data aborts the value sampled is PC+8. Hence the need to subtract before exception return.

EXECUTE can also not fail and in this case any instruction that reads R15 will see PC+8 because it's already incremented by +4 at FETCH and +4 in DECODE before EXECUTE. Hence you always see the PC 8 bytes ahead of the current instruction as a result of MOV Rx, PC.

LR_SVC will reflect PC+4 at exception handler but the most common case is to return to the next instruction. Therefore to see the PC value of the SVC instruction itself YOU have to subtract 4. The exception is taken at EXECUTE even though we pended it in DECODE, so while executing it we can either do one of two things; use PC+4 carries with the pended exception or just use the PC at EXECUTE and the core will subtract 4. Or any other method - how you route execution data around the pipeline is a problem for pipeline designers.

It doesn't REALLY matter since Cortex-A modern pipelines don't look like that. It's all fake to maintain compatibility with software that MUST reflect old behavior. Which is, again, a problem for pipeline designers.

as a software developer wondering why the PC is the value it is or why the LR_SVC value is the value it is, you just need to read the documentation and do what it tells you to expect.