[llvm-dev] Optimised stack direction?
Tim Northover via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 25 15:00:11 PDT 2019
On Tue, 25 Jun 2019 at 22:10, Samuel Williams
<space.ship.traveller at gmail.com> wrote:
> But according to the assembly being generated, there is a fixed layout on the stack. I agree, the code is pretty ambiguous. But it should be well defined within the compiler.
Only in the sense that the compiler tries to be deterministic between
invocations. Detecting actual stack growth direction from that snippet
is fundamentally broken.
LLVM could perfectly legitimately fix a seed and call rand() to decide
which of x & y to put first. More likely is that inlining and stack
slot colouring would perturb them.
> If it changes from compilation unit to compilation unit, so be it, at least given some specific instance of the function, it should be a constant.
Even within a translation unit it can vary. The claim is just about
true if you include static call-stack as part of an "instance", but
you still don't get anything you can reason about in any kind of wider
> We need this operation in Ruby, and generally in coroutines to know how to layout the stack. Some architectures decided it would be a great idea for the stack to grow upwards.
None of the uses listed look compelling enough to optimize to me. It
strikes me as an easily cacheable property at best, at worst one the
interpreter/JIT should know statically before it even thinks about
> I tried it but it doesn't seem to generate a constant either. https://godbolt.org/z/Z5HyEu
I wouldn't expect it to. It has a higher probability of representing a
meaningful fact about the platform than the original though.
More information about the llvm-dev