[PATCH] D77767: Prevent stack coloring functions whith setjmp / longjmp

Diogo N. Sampaio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 14 14:39:23 PDT 2020


dnsampaio added a comment.

Hi @rnk and @efriedma, indeed my initial thoughts were as well the register allocator, specially because using the pbqp allocator there are no spills for this example so it does not fail.
>From what I see in the code it seems that none of the register allocators know anything about `setjmp`. There's an ancient llvm-dev post confirming it: https://lists.llvm.org/pipermail/llvm-dev/2011-October/043731.html

So the doubt I have is, what is the correct solution for it? I guess we can't block a variable from being spilled if it's life-range crosses the `setjmp` function. From my understanding of setjmp/longjmp, for any of such variables, when evicted, needs two spill slots. Spill slot 1 (`ss1`) holds the current value of the variable. Spill slot 2 (`ss2`) holds the variable value right before the `setjmp`, copied from `ss1`. Right after `setfmp` we always copy the `ss2` to `ss1` restoring it. The issue I see with doing it is that it will increase the register pressure at this point of the program by one, as we need it for doing the copying, unless the variable is also live in register at this point, which would avoid the second spill slot all together.

A possible optimization would be finding a lower register pressure point that post-dominates the last may-write to the variable before the setjmp function call and that dominates the function call, if doing so would avoid a second spill.
Does that sound correct to you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77767





More information about the llvm-commits mailing list