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

Jonas Paulsson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 5 04:48:35 PDT 2020


jonpa added a comment.

In D78717#2018725 <https://reviews.llvm.org/D78717#2018725>, @serge-sans-paille wrote:

> > With dynamic allocas, it seems wise to always probe no matter what the size, but the "tail" in emitProbedAlloca() is not probed. This seems flawed to me:
>
> I just had a look to the X86 and indeed, it's a falw, I'll propose a patch.
>
> > As a general note, the code duplication between inlineStackProbe and emitProbedAlloca is a bit unfortunate, not sure if there's a better way here.
>
> I'll explore that aspect too, thanks for the code review :-)


Ah, thanks for clarifying this :-)

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().


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

https://reviews.llvm.org/D78717





More information about the llvm-commits mailing list