This is an archive of the discontinued LLVM Phabricator instance.

All libcalls should be considered to be GC-leaf functions.
ClosedPublic

Authored by dneilson on Jul 25 2017, 7:39 AM.

Details

Summary

It is possible for some passes to materialize a call to a libcall (ex: ldexp, exp2, etc),
but these passes will not mark the call as a gc-leaf-function. All libcalls are
actually gc-leaf-functions, so we change llvm::callsGCLeafFunction() to tell us that
available libcalls are equivalent to gc-leaf-function calls.

Diff Detail

Repository
rL LLVM

Event Timeline

dneilson created this revision.Jul 25 2017, 7:39 AM
dneilson updated this revision to Diff 108083.Jul 25 2017, 7:42 AM

clang-format patch

anna accepted this revision.Jul 27 2017, 8:15 AM

This change looks good to me. However, I would suggest separating out the PlaceSafepoints (and it's testcase) change from the RewriteStatepointsForGC change. We don't use placeSafepoint anymore, so we should perhaps just deprecate it upstream, instead of fixing it.
@reames: What do you suggest?

lib/Transforms/Utils/Local.cpp
1850 ↗(On Diff #108083)

Please state that libcalls can be materialized by RS4GC, there's no other passes right? (frankly, the placeSafepoints.cpp is deprecated).

This revision is now accepted and ready to land.Jul 27 2017, 8:15 AM
In D35840#822809, @anna wrote:

This change looks good to me. However, I would suggest separating out the PlaceSafepoints (and it's testcase) change from the RewriteStatepointsForGC change. We don't use placeSafepoint anymore, so we should perhaps just deprecate it upstream, instead of fixing it.
@reames: What do you suggest?

With the codebase in its current state, the PlaceSafepoints & RewriteStatepointsForGC changes cannot be separated. Fundamentally, the change is to behaviour of callsGCLeafFunction() -- making it flag lib calls as gc-leaf. That change required changing the prototype for the function, which in turn required the change in PlaceSafepoints.

The change could be contained to add the libcall check to just RewriteStatepointsForGC in the NeedsRewrite lambda, but that's less of a proper fix in my view -- it fixes a location of the bug's manifestation, but not the source of the bug.

lib/Transforms/Utils/Local.cpp
1850 ↗(On Diff #108083)

That's not true. Libcalls can be created by other passes than just RS4GC. For example, where we noticed this problem was in a series of simplifications:
pow(x, 2) -> exp2(x) -> ldexp(x, 2)
pow & exp2 are both intrinsics, so we'd have been fine with that simplification, but ldexp does not have an intrinsic form, so the standard lib version is used (i.e. a libcall).

anna added a comment.Jul 27 2017, 9:18 AM
In D35840#822809, @anna wrote:

This change looks good to me. However, I would suggest separating out the PlaceSafepoints (and it's testcase) change from the RewriteStatepointsForGC change. We don't use placeSafepoint anymore, so we should perhaps just deprecate it upstream, instead of fixing it.
@reames: What do you suggest?

With the codebase in its current state, the PlaceSafepoints & RewriteStatepointsForGC changes cannot be separated. Fundamentally, the change is to behaviour of callsGCLeafFunction() -- making it flag lib calls as gc-leaf. That change required changing the prototype for the function, which in turn required the change in PlaceSafepoints.

The change could be contained to add the libcall check to just RewriteStatepointsForGC in the NeedsRewrite lambda, but that's less of a proper fix in my view -- it fixes a location of the bug's manifestation, but not the source of the bug.

SGTM!

lib/Transforms/Utils/Local.cpp
1850 ↗(On Diff #108083)

ah thanks for the clarification.

reames edited edge metadata.Jul 27 2017, 9:39 AM
In D35840#822809, @anna wrote:

This change looks good to me. However, I would suggest separating out the PlaceSafepoints (and it's testcase) change from the RewriteStatepointsForGC change. We don't use placeSafepoint anymore, so we should perhaps just deprecate it upstream, instead of fixing it.
@reames: What do you suggest?

Fixing both is definitely the right answer for the moment. PlaceSafepoints is questionable. It's a nice proof of concept, but given we aren't using it and thus testing it, it's probably starting to bit rot. I'd lean toward removing it, but let's check on llvm-dev to see if anyone else is using it before we just delete the code.

This revision was automatically updated to reflect the committed changes.