This is an archive of the discontinued LLVM Phabricator instance.

[GC] improve testing around gc.relocate and catch a bug
ClosedPublic

Authored by artagnon on Jan 1 2015, 5:38 PM.

Details

Summary

This patch started out as an exploration of gc.relocate, and an attempt
to write a simple test in call-lowering. I then noticed that the
arguments of gc.relocate were not checked fully, so I went in and fixed
a few things. Finally, the most important outcome of this patch is that
my new error handling code caught a bug in a callsite in
stackmap-format.

Diff Detail

Repository
rL LLVM

Event Timeline

artagnon updated this revision to Diff 17755.Jan 1 2015, 5:38 PM
artagnon retitled this revision from to [GC] improve testing around gc.relocate and catch a bug.
artagnon updated this object.
artagnon edited the test plan for this revision. (Show Details)
artagnon added reviewers: reames, sanjoy.
artagnon added a subscriber: Unknown Object (MLST).
sanjoy edited edge metadata.Jan 2 2015, 11:51 AM

Some small nits inline. I'll defer to Philip for an LGTM.

lib/IR/Verifier.cpp
2695 ↗(On Diff #17755)

Should be nullptr

2734 ↗(On Diff #17755)

Might be cleaner to store the result of getZExtValue() in an unsigned instead.

test/CodeGen/X86/statepoint-stackmap-format.ll
30 ↗(On Diff #17755)

You had to make these changes because the original indices are out of range, right?

reames edited edge metadata.Jan 2 2015, 12:00 PM

LGTM w/minor comments addressed. Let me know if you want me to submit.

lib/IR/Verifier.cpp
2695 ↗(On Diff #17755)

Did you manage to find a way to make this fail without the change?

I might structure this as an assert and early exit on the getInstruction check. It would be clearer. (This is entirely optional.)

2734 ↗(On Diff #17755)

While Sanjoy's right, you'd don't need to fix my pre-existing style problems in your change. :)

test/CodeGen/X86/statepoint-call-lowering.ll
65 ↗(On Diff #17755)

"that a no-op relocate" what?

p.s. Given the relocated value isn't used, this is testing less than it might seem. In particular, the 'relocation' is not actual lowered and exists only in the IR. Is that what you intended?

test/CodeGen/X86/statepoint-stackmap-format.ll
30 ↗(On Diff #17755)

I'll just say "oops!". Thanks for catching this.

artagnon added inline comments.Jan 2 2015, 12:02 PM
lib/IR/Verifier.cpp
2734 ↗(On Diff #17755)

Actually, I copied that out from the gc_statepoint case code: would you like me to change the instances on lines 2624 and 2650 too, for consistency?

test/CodeGen/X86/statepoint-stackmap-format.ll
30 ↗(On Diff #17755)

Technically, the original indices didn't fall within the 'gc parameters' section of the arguments: argument #3 reads i32 2, which means that '4' and '5' refer to the two following deopt parameters.

artagnon added inline comments.Jan 2 2015, 12:07 PM
lib/IR/Verifier.cpp
2695 ↗(On Diff #17755)

No, I didn't make it actually fail; I just noticed this check in surrounding code and thought I should put it in here too. It's not about an early exit from getInstruction(); it's about reporting the correct frontend error, I think.

test/CodeGen/X86/statepoint-call-lowering.ll
65 ↗(On Diff #17755)

Yep, that's exactly what I intended: to show that it isn't lowered. Should I put a CHECK-NOT or something?

artagnon updated this revision to Diff 17762.Jan 2 2015, 12:23 PM
artagnon edited edge metadata.

Fix nits caught by {sanjoy,reames} review.

reames added inline comments.Jan 2 2015, 2:16 PM
lib/IR/Verifier.cpp
2695 ↗(On Diff #17755)

Either is fine. You could be slightly more fine grained, but I don't see that doing so actually adds anything.

i.e. The difference between "this is not a statepoint token" and "this is not a statepoint token and not a call or inst" seems minor at best.

2734 ↗(On Diff #17755)

If you're going to change it once, please change it everywhere. I would prefer you did that as a separate change, but not strongly so.

test/CodeGen/X86/statepoint-call-lowering.ll
65 ↗(On Diff #17755)

Use check-next to make sure there's no other instructions and add a comment stating that. It's not at all obvious.

artagnon updated this revision to Diff 17765.Jan 2 2015, 2:32 PM
  1. Revert const int -> unsigned changes, since reames would like it in a different commit.
  1. Use CHECK-NEXT as reames suggests, in the test. Clarify what we're testing.
  1. Leave the getInstruction() ternary check intact. We might factor it out in a separate change.
reames added a comment.Jan 2 2015, 2:37 PM

LGTM w/minor comment tweak. Do you want me to submit on your behalf?

test/CodeGen/X86/statepoint-call-lowering.ll
65 ↗(On Diff #17765)

You're missing something key here. A suggestion:
"This is checking that an *unused* relocate has no code generation impact."

Sure, do submit with the comment tweak.

I'm yet to figure out how relocate should actually be used: I didn't quite get what happens when base index = derived index.

(After watching the LLVMDev talk): Did you mean that the result of the relocate is unused, and hence no code is generated? If I did %a = gc.relocate(...), and then used %a in another gc.statepoint call, then a mov will be generated like in statepoint-stack-usage.ll? The mov is generated because it's assuming that the gc is relocating the base, and then returning a new derived with some offset (= the original derived - base) for use with the second gc.statepoint?

Ping.

Reames: would you like me to do anything else?

I'm yet to figure out how relocate should actually be used: I didn't quite get what happens when base index = derived index.

This means that the pointer itself is a base pointer. This is extremely common and well supported.

(After watching the LLVMDev talk): Did you mean that the result of the relocate is unused, and hence no code is generated? If I did %a = gc.relocate(...), and then used %a in another gc.statepoint call, then a mov will be generated like in statepoint-stack-usage.ll? The mov is generated because it's assuming that the gc is relocating the base, and then returning a new derived with some offset (= the original derived - base) for use with the second gc.statepoint?

I'm having a hard time parsing your question.

Let me lay out a few facts; I think that together these address what you're getting at.

  1. Once inserted, any use (even a trivial one) will cause the pointer to be saved in the stackmap.
  2. For a derived pointer to be relocated, it's base pointer must be as well. (If the derived pointer is a base pointer, this is trivial.)
  3. The offset between a relocated derived pointer and it's relocated base must be the same as the offset between the original derived pointer and the original base.

W.r.t. this patch, is it ready for submission? Or does the clarification above change something? Once you consider it ready, let me know and I'll submit on your behalf.

artagnon updated this revision to Diff 17870.Jan 7 2015, 12:22 PM

Update comment in call-lowering, and rebase onto latest master.

@reames: Thanks for the clarifying comments; I have a better
understanding now. It's ready to land now, I think.

This revision was automatically updated to reflect the committed changes.