Refactor GCTDecl.h, and mitigate #7602 a bit
authorAustin Seipp <austin@well-typed.com>
Tue, 28 Jan 2014 12:15:19 +0000 (06:15 -0600)
committerAustin Seipp <austin@well-typed.com>
Tue, 28 Jan 2014 12:54:58 +0000 (06:54 -0600)
commit28b031c506122e28e0230a562a4f6fd3d0256d0c
treeecba3eb2c23549b931339e13ab9d52025b50d6fc
parentf9652e22da592ec0689b4919c003c67dacf28d31
Refactor GCTDecl.h, and mitigate #7602 a bit

This basically cleans a lot of GCTDecl up - I found it quite hard to
read and a bit confusing. The changes are mostly cosmetic: better
delineation between the alternative cases and light touchups, and tries
to make every branch as consistent as possible.

However, this patch does have one significant effect: it will ensure
that any LLVM-based compilers will use __thread if they support it.
Before, they would simply always use pthread_getspecific and
pthread_setspecific, which are almost surely even *more* inefficient.

The details are a bit too long and boring to go into here; see #7602.
After talking with Simon, we decided to play it safe - __thread can at
least be optimized by future clang releases even further on OS X if they
choose, and it's safer until we can investigate the pthread
implementation further on Mavericks.

For Linux, the story isn't so bleak if you use Clang (for whatever
reason) - Linux directly writes to `%fs` for __thread slots (while OS X
will perform a load followed by an indirect call.) So it should still be
fairly competitive, speed-wise.

Signed-off-by: Austin Seipp <austin@well-typed.com>
rts/sm/GCTDecl.h