This is an archive of the discontinued LLVM Phabricator instance.

BypassSlowDivision: Fix dropping debug info
ClosedPublic

Authored by arsenm on Jun 11 2020, 1:05 PM.

Details

Summary

I don't know anything about debug info, but this seems like more work
should be necessary. This constructs a new IRBuilder and reconstructs
the original divides rather than moving the original.

One problem this has is if a div/rem pair are handled, both end up
with the same debugloc. I'm not sure how to fix this, since this uses
a cache when it sees the same input operands again, which will have
the first instance's location attached.

Diff Detail

Event Timeline

arsenm created this revision.Jun 11 2020, 1:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 11 2020, 1:05 PM
vsk added a subscriber: vsk.Jun 11 2020, 6:47 PM

Re: "This constructs a new IRBuilder and reconstructs the original divides rather than moving the original", you're not changing the algorithm here, just the way locations are assigned, right? Not sure I understand what's meant by 'reconstructs the original divides'.

llvm/lib/Transforms/Utils/BypassSlowDivision.cpp
441

Is it simpler to just pass in the builder (which has the location set already)?

llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
29

I think this is good? At least, it seems better than having the source location of the srem (!10) appear in the fast block.

arsenm marked 2 inline comments as done.Jun 11 2020, 7:21 PM
In D81685#2088957, @vsk wrote:

Re: "This constructs a new IRBuilder and reconstructs the original divides rather than moving the original", you're not changing the algorithm here, just the way locations are assigned, right? Not sure I understand what's meant by 'reconstructs the original divides'.

I mean mechanically it produces a new IR instruction and deletes the old instruction, rather than move the old instruction to the new block

llvm/lib/Transforms/Utils/BypassSlowDivision.cpp
441

I did that originally, but it didn't work in all of the cases (which required getting the DebugLoc from FastDivInsertionTask). Since I had to track it separately anyway, it seemed cleaner to always get it from there

llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
29

I would hope the rem would get the location of the original rem, but I guess this is better than nothing (especially for architectures where these will end up merging into SDIVREM/UDIVREM later anyway)

aprantl added inline comments.Jun 12 2020, 10:39 AM
llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
32

Can you replace !6 with ![[DBG:[0-9]+]]

and the CHECK that DBG is the expected location? The numbering isn't really guaranteed.

vsk added inline comments.Jun 12 2020, 10:52 AM
llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
29

One issue with using the location of the original rem is that single-stepping would look like 'line 3 -> line 4 -> line 3'. It's unfortunate to lose the unique breakpoint location for the rem, but if there were a second rem that used the cached value, this would happen anyway.

arsenm marked an inline comment as done.Jun 12 2020, 10:54 AM
arsenm added inline comments.
llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
32

That would mean switching to handwritten checks rather than update_test_checks

arsenm marked an inline comment as done.Jun 15 2020, 11:35 AM
arsenm added inline comments.
llvm/test/Transforms/CodeGenPrepare/AMDGPU/bypass-slow-div-debug-info.ll
32

I think it would be more painful to have manually written checks to avoid hardcoding the number than to just regenerate the test if these numbers were to ever change.

vsk accepted this revision.Jun 15 2020, 2:01 PM

This looks good to me. I think using update_test_checks here is fine, but could you leave this up for another day or so to give Adrian a chance to review?

This revision is now accepted and ready to land.Jun 15 2020, 2:01 PM