Page MenuHomePhabricator

[Sparc] Improve the builtin setjmp/longjmp
AbandonedPublic

Authored by dcederman on Aug 20 2018, 5:49 AM.

Details

Reviewers
jyknight
venkatra
Summary

The current version does not always generate correct code and fails the -verify-machineinstrs test.

This patch makes the following changes:

  • Require base address of jmp_buf to be in a single register. This simplifies things as there is always room for the offset in the immediate field.
  • Chain longjmp with a FLUSHW to get a platform independent register window flush before going up the stack.
  • Use LDX/STX for 64-bit systems.
  • Simplify emitEHSjLjLongJmp with a for-loop.
  • Use a register mask to force reload of data into registers after a longjmp.
  • Use a call instruction to get the return address. This allows the same code to be used for 64-bit systems and with position-independent code.

I have only tested it on a 32-bit system.

Diff Detail

Event Timeline

dcederman created this revision.Aug 20 2018, 5:49 AM

Dare I ask -- are you fixing them because you're testing with -verify-machineinstrs and fixing the failures, or because you actually want it for something?

That is -- can we just delete support for sjlj setjmp/longjmp from the sparc backend, instead?

I'm fixing them for the failures and to learn about LLVM. I have no use case and I'm perfectly fine with and in favor of removing the support. Can I just revert the patch that introduced the support, or should I submit a removal patch for review?

A revert won't apply cleanly by now, so probably best to make a review for it. I suspect it's simpler to just delete the code as it is now, rather than try to actually do a git revert.

joerg added a subscriber: joerg.Aug 29 2018, 2:40 PM

There is one user of builtin_setjmp/builtin_longjmp that should be kept in mind: Ruby.

There is one user of __builtin_setjmp/__builtin_longjmp that should be kept in mind: Ruby.

As far as I'm aware, it _can_ use it, but is perfectly happy not to, and will use _setjmp or sigsetjmp or setjmp otherwise.

https://github.com/ruby/ruby/blob/master/tool/m4/ruby_setjmp_type.m4

joerg added a comment.Aug 29 2018, 3:44 PM

Yes, it is optional, but on most architectures, the builtin variant is much cheaper. That said, I'm not sure what the situation is on SPARC with the necessary register window flush.