[PATCH] D78717: [SystemZ] Implement -fstack-clash-protection

[Andy Ayers via Phabricator via llvm-commits]

AndyAyers added a comment.

In D78717#2022095 <https://reviews.llvm.org/D78717#2022095>, @jonpa wrote:

> >> It would also be useful if you could explain the comment you added "stack probing may involve looping, and control flow generations is disallowed at this point. Rely to later processing through `inlineStackProbe`".  Is this still true? It probably is, I just can't see why this is needed since emitPrologue() and inlineStackProbe() are run nearly right after eachother in PEI::insertPrologEpilogCode().
> > 
> > It's clearer if I just state that we're reusing the existing probe infrastructure. I'm not a MachineInstruction expert and don't recall why I wrote this :-/
>
> Ah, I see. I suppose then that it is sort of "voluntary" for a target to take the trouble of using the stub with metadata, depending on if it would simplify things? The original comment by Andy Ayers in his commit message from 2015 ( 809cbe9) formulates this in a weaker way: "to avoid complications". I am not sure exactly what complications that might arise (in the case where an MBB is both a SaveBlock and RestoreBlock the particular way of splitting may get more complicated, perhaps?), but perhaps it would avoid confusion if you changed your comment to use Andys wording instead...
>
> @AndyAyers : Do you recall your reasons from back then?


Unfortunately, no. I did a quick look for notes I might have made at the time and didn't find any.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78717/new/

https://reviews.llvm.org/D78717