[llvm-dev] Optimised stack direction?

[Samuel Williams via llvm-dev]

Tim, everything you state makes sense. Thanks for explaining things to me.

Clearly, adding a new intrinsic does't solve the problem for existing
platforms which need to be supported.

That being said:

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.

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.

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.

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.

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.

Kind regards,
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/1cc425f0/attachment.html>