This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] Yet another approach to __tls_get_addr
ClosedPublic

Authored by wschmidt on Feb 2 2015, 11:31 AM.

Details

Summary

This patch is a third attempt to properly handle the local-dynamic and global-dynamic TLS models.

In my original implementation, calls to __tls_get_addr were hidden from view until the asm-printer phase, at which point the underlying branch-and-link instruction was created with proper relocations. This mostly worked well, but I used some repellent techniques to ensure that the TLS_GET_ADDR nodes at the SD and MI levels correctly received input from GPR3 and produced output into GPR3. This proved to work badly in the presence of multiple TLS variable accesses, with the copies to and from GPR3 being scheduled incorrectly and generally creating havoc.

In r221703, I addressed that problem by representing the calls to __tls_get_addr as true calls during instruction lowering. This had the advantage of removing all of the bad hacks and relying on the existing call machinery to properly glue the copies in place. It looked like this was going to be the right way to go.

However, as a side effect of the recent discovery of problems with linker optimizations for TLS, we discovered cases of suboptimal code generation with this strategy. The problem comes when tls_get_addr is called for the same address, and there is a resulting CSE opportunity. It turns out that in such cases MachineCSE will common the addis/addi instructions that set up the input value to tls_get_addr, but will not common the calls themselves. MachineCSE does not have any machinery to common idempotent calls. This is perfectly sensible, since presumably this would be done at the IR level, and introducing calls in the back end isn't commonplace. In any case, we end up with two calls to __tls_get_addr when one would suffice, and that isn't good.

I presumed that the original design would have allowed commoning of the machine-specific nodes that hid the __tls_get_addr calls, so as suggested by Ulrich Weigand, I went back to that design and cleaned it up so that the copies were properly held together by glue nodes. However, it turned out that this didn't work either...the presence of copies to physical registers kept the machine-specific nodes from being commoned also.

All of which leads to the design presented here. This is a return to the original design, except that no attempt is made to introduce copies to and from GPR3 during instruction lowering. Virtual registers are used until prior to register allocation. At that point, a special pass is run that identifies the machine-specific nodes that hide the tls_get_addr calls and introduces the copies to and from GPR3 around them. The register allocator then coalesces these copies away. With this design, MachineCSE succeeds in commoning tls_get_addr calls where possible, and we get nice optimal code generation (better than GCC at the moment, which does not common these calls).

This is a relatively large patch, but a great deal of it is simply undoing the changes made by r221703. The interesting bits are:

  • PPCFrameLowering.cpp forces a stack frame when LR must be saved
  • Slight changes in PPCISelLowering.cpp to use virtual registers for GET_TLS_ADDR nodes
  • Use of "let Defs = [LR]" (or [LR8]) in PPCInstrinfo.td and PPCInstr64Bit.td
  • The new pass in PPCInstrInfo.cpp
  • Test cases

One thing missing from the original design was recording a definition of the link register on the GET_TLS_ADDR nodes. Doing this was found to be insufficient to force a stack frame to be created, which led to looping behavior because two different LR values were stored at the same address. This appears to have been an oversight in PPCFrameLowering::determineFrameLayout(), though there might be a better way to fix this. Hal, I'd be interested in your thoughts on that.

Because MustSaveLR() returns true for calls to builtin_return_address, this changed the expected behavior of test/CodeGen/PowerPC/retaddr2.ll, which now stacks a frame but formerly did not. I believe the new behavior is more correct, but would like your opinion on this as well.

Currently the pass is set to occur always. I don't think we can restrict it to run only for certain values of TM.getRelocationModel(), since individual variables can be annotated with the TLS model to be used. But if there is a safe way to avoid the pass sometimes, that would be nice (although it is a very fast pass).

Chandler, Kit, Nemanja, Bill: I listed you as reviewers, but you can consider this as more of an FYI. Review is welcome but not required. Thanks!

Diff Detail

Event Timeline

wschmidt updated this revision to Diff 19164.Feb 2 2015, 11:31 AM
wschmidt retitled this revision from to [PowerPC] Yet another approach to __tls_get_addr.
wschmidt updated this object.
wschmidt edited the test plan for this revision. (Show Details)
wschmidt added a subscriber: Unknown Object (MLST).
hfinkel accepted this revision.Feb 2 2015, 12:45 PM
hfinkel edited edge metadata.

This is great, thanks! With the changes noted below, LGTM.

lib/Target/PowerPC/PPCAsmPrinter.cpp
820

Can there be an assert here that the relevant operands are actually equal to PPC::X3 or PPC::R3? If so, please add one.

881

Can you please refactor the code here so that it shares as much as possible with the PPC::GETtlsADDR/PPC::GETtlsADDR32 handling above. It looks quite similar.

lib/Target/PowerPC/PPCInstr64Bit.td
904

No need for the { } around on def.

921

Same here (no { } needed).

lib/Target/PowerPC/PPCInstrInfo.cpp
2281

When you rebase, you'll discover that I just moved all of these other passes into separate files. Please don't add it here, but rather add a separate file. I think that this file becomes somewhat unwieldy with a collection of passes tacked on to the end.

2290

Please explain why we're doing this here (that it turns into a call, and thus the register choice is actually constrained).

lib/Target/PowerPC/PPCInstrInfo.td
2511

You don't need the { } around a single following def.

2521

Same here (no { } needed).

This revision is now accepted and ready to land.Feb 2 2015, 12:45 PM
hfinkel added inline comments.Feb 2 2015, 6:03 PM
lib/Target/PowerPC/PPCInstr64Bit.td
905

To follow-up on the IRC messages I missed, to keep the anti-dep breaker from disturbing the r3 assignments, you'll probably want to set let hasExtraSrcRegAllocReq = 1, and/or hasExtraDefRegAllocReq = 1 here (and on the other pseudos in this patch).

wschmidt closed this revision.Feb 3 2015, 8:19 AM

Revised to address Hal's comments. I also had to add flags to the GETtls* instruction definitions to keep the aggressive anti-dependency breaker from touching the mentions of GPR3.

Committed as r227976. Thanks for the review!

Bill