On 06/19/2017 11:29 AM, Jakub Jelinek wrote: > > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack, > while it is shorter, is it actually faster or as slow as movq $0, (%rsp) > or movl $0, (%esp) ? Florian raised this privately to me as well. THere's a couple issues.
1. Is there a performance penalty/gain for sub-word operations? If not, we can improve things slighly there. Even if it's performance neutral we can probably do better on code size. 2. I would *prefer* if the probe actually changed the value, and the more destructive, the better :-0 It allows catching something gone wild easier. These are pretty minor implementation details IMHO, but now is a good time to revisit the probe style. I'm mostly concerned about holes in the basic probing strategy, how we're going to deal with the additional architectures (I can't imagine we'll want to go through the pain of a custom implementation for each target) and the UI. On the last topic. When we first started this work, it appeared like we could make most targets with -fstack-check=specific support work (possibly with some inefficiency) by just dropping the probe-ahead-of-need aspects of the existing implementation. ie, we'd drop the requirement for being able to run the signal handler and stop probing 2 pages beyond the current stack requirements and instead just probe up to what the current function needed. This felt like a "probing policy" (ahead-of-need vs as-needed). But when we ran into the issues with valgrind it became clear that we really couldn't safely use the current port support for -fstack-check=specific. Thus I find myself rethinking is this a probing policy option or should it just be another variant of -fstack-check=<something>. Jeff