This is an archive of the discontinued LLVM Phabricator instance.

[NVPTX] Lower instructions that expands into libcalls
ClosedPublic

Authored by denzp on Nov 30 2018, 1:43 PM.

Details

Summary

The change is an effort to split and refactor abandoned D34708 into smaller parts.

Here the behaviour of unsupported instructions is changed to match the behaviour of explicit intrinsics calls. Currently LLVM crashes with:
Assertion getInstruction() && "Not a call or invoke instruction!" failed.

Diff Detail

Repository
rL LLVM

Event Timeline

denzp created this revision.Nov 30 2018, 1:43 PM
tra added a comment.Dec 7 2018, 5:02 PM

Here the behaviour of unsupported instructions is changed to match the behaviour of explicit intrinsics calls.

If I remember correctly, the crash was only happening for instructions lowered to libcall. Do we crash in any other case?
If libcall is the only source of failure, would it make more sense to bail out of this function early? We're going to fail in this case anyways.

denzp added a comment.Dec 14 2018, 8:55 AM
In D55145#1324230, @tra wrote:

Here the behaviour of unsupported instructions is changed to match the behaviour of explicit intrinsics calls.

If I remember correctly, the crash was only happening for instructions lowered to libcall. Do we crash in any other case?
If libcall is the only source of failure, would it make more sense to bail out of this function early? We're going to fail in this case anyways.

You are right, normally it would make sense. But in this case, the end goal is to support these libcalls.
It would be easier to achieve when both instructions and intrinsics are behaving consistently. And I'm afraid, bailing them out, would be an extra work that will have to be dropped when the final libcall solution will come (means, very-very soon).

tra accepted this revision.Dec 14 2018, 9:29 AM
In D55145#1324230, @tra wrote:

Here the behaviour of unsupported instructions is changed to match the behaviour of explicit intrinsics calls.

If I remember correctly, the crash was only happening for instructions lowered to libcall. Do we crash in any other case?
If libcall is the only source of failure, would it make more sense to bail out of this function early? We're going to fail in this case anyways.

You are right, normally it would make sense. But in this case, the end goal is to support these libcalls.
It would be easier to achieve when both instructions and intrinsics are behaving consistently. And I'm afraid, bailing them out, would be an extra work that will have to be dropped when the final libcall solution will come (means, very-very soon).

OK.

The patch looks good to me.
One nit: I would suggest changing couple of conditional expressions that depend on !IsIndirectCall to use it without negation. It's a bit easier to read and understand.

lib/Target/NVPTX/NVPTXISelLowering.cpp
1681 ↗(On Diff #176192)

-> = isIndirectCall ? NVPTXISD::PrintCall : NVPTXISD::PrintCallUni;

1715 ↗(On Diff #176192)

!isIndirectCall ? 1 : 0 -> isIndirectCall ? 0 : 1

This revision is now accepted and ready to land.Dec 14 2018, 9:29 AM
denzp updated this revision to Diff 178299.Dec 14 2018, 2:50 PM
denzp marked 2 inline comments as done.

Done, thanks for the suggestion! Could you please commit it?

This revision was automatically updated to reflect the committed changes.