`[source] `_ compiler/cmm/CmmProcPoint.hs ============================ Note [Proc-point analysis] ~~~~~~~~~~~~~~~~~~~~~~~~~~ `[note link] `__ Given a specified set of proc-points (a set of block-ids), "proc-point analysis" figures out, for every block, which proc-point it belongs to. All the blocks belonging to proc-point P will constitute a single top-level C procedure. A non-proc-point block B "belongs to" a proc-point P iff B is reachable from P without going through another proc-point. Invariant: a block B should belong to at most one proc-point; if it belongs to two, that's a bug. Note [Non-existing proc-points] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `[note link] `__ On some architectures it might happen that the list of proc-points computed before stack layout pass will be invalidated by the stack layout. This will happen if stack layout removes from the graph blocks that were determined to be proc-points. Later on in the pipeline we use list of proc-points to perform [Proc-point analysis], but if a proc-point does not exist anymore then we will get compiler panic. See #8205. Note [Separate Adams optimization] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `[note link] `__ It may be worthwhile to attempt the Adams optimization by rewriting the graph before the assignment of proc-point protocols. Here are a couple of rules: :: g() returns to k; g() returns to L; k: CopyIn c ress; goto L: ... ==> ... L: // no CopyIn node here L: CopyIn c ress; .. And when c == c' and ress == ress', this also: :: g() returns to k; g() returns to L; k: CopyIn c ress; goto L: ... ==> ... L: CopyIn c' ress' L: CopyIn c' ress' ; .. In both cases the goal is to eliminate k.