This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] fix potential verification error on __tls_get_addr
ClosedPublic

Authored by inouehrs on Jun 19 2017, 5:21 AM.

Details

Summary

This patch fixes a verification error with -verify-machineinstrs while expanding __tls_get_addr by not creating ADJCALLSTACKUP and ADJCALLSTACKDOWN if there is another ADJCALLSTACKUP in this basic block since nesting ADJCALLSTACKUP/ADJCALLSTACKDOWN is not allowed.

Here, ADJCALLSTACKUP and ADJCALLSTACKDOWN are created as a fence for instruction scheduling to avoid _tls_get_addr is scheduled before mflr in the prologue (https://bugs.llvm.org//show_bug.cgi?id=25839). So if another ADJCALLSTACKUP exists before _tls_get_addr, we do not need to create a new ADJCALLSTACKUP.

With this patch and two previous patches (https://reviews.llvm.org/D34208 and https://reviews.llvm.org/D34209), I successfully compiled LLVM+CLANG with -verify-machineinstrs on ppc64le Linux.

Diff Detail

Repository
rL LLVM

Event Timeline

inouehrs created this revision.Jun 19 2017, 5:21 AM
nemanjai edited edge metadata.Jun 19 2017, 10:56 PM

I think we should add a test case for this. Of course, since these are pseudo instructions we're dealing with, it would probably have to be an mir test.

lib/Target/PowerPC/PPCTLSDynamicCall.cpp
61 ↗(On Diff #103019)

If the ADJCALLSTACKDOWN instruction is guaranteed to occur before any of the "TLS" pseudos in a basic block, that should be mentioned in a comment here. If on the other hand it isn't guaranteed to happen, we can form adjacent ADJCALLSTACKDOWN/ADJCALLSTACKUP blocks.

I don't imagine that's a problem, but it is somewhat inconsistent here...
What I mean is that if this loop encounters an ADJCALLSTACKDOWN which is followed by an ADJCALLSTACKUP, we will still not emit the instructions for the subsequent TLS instructions. I am not sure if that is a problem or not.

So the crux of what I'm saying here is this:

...
ADJCALLSTACKDOWN
...
ADJCALLSTACKUP
...
ADDItlsgdLADDR

Will not add the adjustments. Whereas this will (for all of the TLS instructions):

...
ADDItlsgdLADDR
...
ADDItlsgdLADDR

And this will add the adjustments only for the TLS instructions that appear before the stack adjustments that were already there:

...
ADDItlsgdLADDR
...
ADJCALLSTACKDOWN
...
ADJCALLSTACKUP
...
ADDItlsgdLADDR
inouehrs updated this revision to Diff 103238.Jun 20 2017, 11:09 AM
  • added MIR test cases
  • added initialization of ppc-tls-dynamic-call pass to use with llc -run-pass
  • updated the logic to check existing ADJCALLSTACKUP as well as ADJCALLSTACKDOWN
inouehrs added inline comments.Jun 20 2017, 11:21 AM
lib/Target/PowerPC/PPCTLSDynamicCall.cpp
61 ↗(On Diff #103019)

I modified the logic to be more consistent. Now the following two cases both generate the adjustments.

...
ADJCALLSTACKDOWN
...
ADJCALLSTACKUP
...
ADDItlsgdLADDR

and

...
ADDItlsgdLADDR
...
ADDItlsgdLADDR
nemanjai accepted this revision.Jun 21 2017, 4:43 AM

OK, this LGTM now. I'll approve this patch but give Tim and Kit a day or two to respond if they're interested in doing so before committing this.

This revision is now accepted and ready to land.Jun 21 2017, 4:43 AM
hfinkel added inline comments.
lib/Target/PowerPC/PPCTLSDynamicCall.cpp
112 ↗(On Diff #103238)

This comment does not explain the "Here, ADJCALLSTACKUP and ADJCALLSTACKDOWN are created as a fence for instruction scheduling to avoid _tls_get_addr is scheduled before mflr in the prologue". I realize that this is a pre-existing issue, but while you're here, we should document this better.

inouehrs updated this revision to Diff 103539.Jun 22 2017, 2:09 AM

Touch up comments

inouehrs added inline comments.Jun 22 2017, 2:11 AM
lib/Target/PowerPC/PPCTLSDynamicCall.cpp
112 ↗(On Diff #103238)

Thank you for the comment. I added some description on the intention of these ADJCALLSTACKDOWN/UP.

This revision was automatically updated to reflect the committed changes.