<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Tim, everything you state makes sense. Thanks for explaining things to me.<div><br></div><div>Clearly, adding a new intrinsic does't solve the problem for existing platforms which need to be supported.</div><div><br></div><div>That being said:</div><div><br></div><div>We are definitely not the only ones in this situation. I've been looking at  several "broken" implementations over the past few hours to try and understand what is the best approach.<br></div><div><br></div><div>We definitely want to know the stack direction at compile time if possible, because we want to avoid conditional branches and reduce the amount of code on the hot path.<br><div><br></div><div>The use case really has nothing to do with the interpreter/JIT but more about implementing green threads and manually created stacks. We currently have a macro in Ruby `STACK_DIR_UPPER(x,y)` which emits `x` if stack grows up, and `y` if stack grows down. For most platforms, it's resolved at compile time, which is perfect.</div></div><div><br></div><div>If it's trivial to add something like `__builtin_stack_direction()`, it could probably help avoid a lot of problems in the future for code that needs to resolve this issue. The most common "general" implementation I've seen passes the address of a local to a 2nd function and compares the addresses that way, so it's very similar to the approach using __builtin_frame_address, but that itself doesn't get optimised out.</div><div><br></div><div>Even if we can use `__builtin_frame_address`, which is great because it's supported today, we need to use `configure` test to determine stack direction if we want it resolved at compile time. So, I wish we can use this approach (as you state it's probably more meaningful), but that it can also be resolved at compile time by better optimisation.</div><div><br></div><div>Kind regards,</div><div>Samuel</div></div></div></div></div>