c - How is speculative fault due to compiler optimization implemented under the hood? -

this question follow-up question on can c compiler optimizer violate short-circuiting , reorder memory accesses operands in logical-and expression?.

consider following code.

if (*p && *q) {     /* */ } 

now per discussion @ can c compiler optimizer violate short-circuiting , reorder memory accesses operands in logical-and expression? (especially david schwartz comment , answer) possible optimizer of standard-conformant c compiler emit cpu instructions accesses *q before *p while still maintaining observable behaviour of sequence point established &&-operator.

therefore although optimizer may emit code accesses *q before *p, still needs ensure side-effects of *q (such segmentation fault) observable if *p non-zero. if *p zero, fault due *q should not observable, i.e. speculative fault occur first due *q being executed first on cpu speculative fault ignored away once *p executed , found 0.

my question: how speculative fault implemented under hood?

i appreciate if throw more light on following points while answering question.

1. as far know, when cpu detects fault, generates trap, kernel must handle (either take recovery action such page swap, or signal fault such sigsegv process). correct?
2. so if compiler must emit code perform speculative fault, appears me kernel , compiler (and possibly cpu too) must cooperate each other implement speculative fault. how compiler emit instructions tell kernel or cpu fault generated due code should considered speculative?

it implemented part of normal speculative fetching process. result of speculative fetch, whether it's numerical result or fault, speculative. used if, , if, later needed.

as far know, when cpu detects fault, generates trap, kernel must handle (either take recovery action such page swap, or signal fault such sigsegv process). correct?

the result of executing non-speculatively fetch produces fault trap. result of executing fetch produces fault speculatively speculative trap occur if result of speculative fetch used. if think it, speculative fetches impossible without mechanism.

so if compiler must emit code perform speculative fault, appears me kernel , compiler (and possibly cpu too) must cooperate each other implement speculative fault. how compiler emit instructions tell kernel or cpu fault generated due code should considered speculative?

the compiler placing fetch *q after test on result of *p. signals cpu fetch speculative , can use results once result of test on result of *p known.

the cpu can, , does, perform fetch of *q before knows whether needs or not. essential because fetch can require inter-core operations slow -- wouldn't want wait longer needed. modern multi-core cpus implement aggressive speculative fetching.

this modern cpus do. (the answer cpus explicit speculative fetch operations different.)