This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] Missing location debug information with -O2.
ClosedPublic

Authored by CarlosAlbertoEnciso on Aug 17 2018, 2:23 AM.

Details

Summary

For the below test:

typedef float __attribute__((__vector_size__(16))) f4;
f4 get();
int main() {
   float MyVar = get()[0];
   if (MyVar)
     return 1;
}

Debug location information for 'MyVar' is missing with -O2.

Check that Machine CSE correctly handles during the transformation, the
debug location information for local variables.

Diff Detail

Repository
rL LLVM

Event Timeline

aprantl added inline comments.Aug 17 2018, 8:44 AM
lib/CodeGen/MachineInstr.cpp
2029 ↗(On Diff #161183)

I understand that this is not your code, but is there a way to use the list of USEs instead of linearily scanning through all instructions? I'm not sure if MIR has that capability, so it's possible that the answer is no.

vsk added a comment.Aug 17 2018, 10:41 AM

Thanks for doing this!

lib/CodeGen/MachineInstr.cpp
2029 ↗(On Diff #161183)

MachineInstrIterator::use_instructions(Reg) should do it, and a MRI should be available in the contexts where collecting debug values is a useful thing to do. @CarlosAlbertoEnciso would you mind trying that out? It might require moving collectDebugValues elsewhere, but it could be a nice simplification. (I haven't tried this myself, & it's possible this won't work out, in which case we can look at it in a follow-up.)

test/Transforms/EarlyCSE/debuginfo-locations-dce.ll
2 ↗(On Diff #161183)

Since you're modifying the backend CSE pass, and the test requires a host compiler with X86 support, I think this test belongs in test/CodeGen/X86.

vsk added a subscriber: mattd.Aug 17 2018, 10:42 AM
vsk added inline comments.
lib/CodeGen/MachineInstr.cpp
2029 ↗(On Diff #161183)
lib/CodeGen/MachineInstr.cpp
2029 ↗(On Diff #161183)

Thanks for your feedback. It is a good point. I will have a look at it and see if such functionality is available.

2029 ↗(On Diff #161183)

Thanks for your feedback.

It seems what @aprantl is referring to. I am happy to trying that out.

test/Transforms/EarlyCSE/debuginfo-locations-dce.ll
2 ↗(On Diff #161183)

Thanks for your feedback.

Good point. I will move the test to that specific location.

Following feedback from the reviewers:

  • Move test case to a more suitable location: test/CodeGen/X86
  • Modify 'collectDebugValues' to use MRI USEs.
CarlosAlbertoEnciso marked 2 inline comments as done.Aug 21 2018, 6:53 AM
CarlosAlbertoEnciso marked an inline comment as done.
vsk added a comment.Aug 21 2018, 10:26 AM

This is looking really good. I think it's great that the test exercises more than just MachineCSE in isolation. Just two more minor comments (inline) --

include/llvm/CodeGen/MachineInstr.h
1528 ↗(On Diff #161695)

This function won't work as intended if MRI is null. Could you make it a reference so that future developers know to pass in a valid object?

lib/CodeGen/MachineInstr.cpp
2037 ↗(On Diff #161695)

While we're improving this utility, wdyt of removing this clear? It doesn't seem to be necessary.

CarlosAlbertoEnciso marked 2 inline comments as done.Aug 24 2018, 4:45 AM
In D50887#1207849, @vsk wrote:

This is looking really good. I think it's great that the test exercises more than just MachineCSE in isolation. Just two more minor comments (inline) --

Due to an overlooking of my part, the previous patch caused some test cases to fail (check-all). Basically the following code is incorrect:

void MachineInstr::collectDebugValues(MachineRegisterInfo *MRI,
                                SmallVectorImpl<MachineInstr *> &DbgValues) {
  const MachineOperand &MO = getOperand(0);
  if (!MO.isReg())
    return;

  for (MachineInstr &DI : MRI->use_instructions(MO.getReg()))
    if (DI.isDebugValue())
      DbgValues.push_back(&DI);
}

As it is returning all the instructions that use that specific register, causing some tests to fail (accessing invalid instructions).

The original implementation, returns the debug instructions following the given instruction (MI) within the same basic block.

I reviewed the patch, trying to replicate the original list of debug instructions and the additional steps are required:

  1. Ignore all instructions before MI
  2. Ignore MI
  3. Traverse the instructions after MI within the same basic block

I think step (1) adds extra work and makes the function more expensive that the original implementation. Basically, steps (2) and (3) are the original implementation.

There is a similar code that finds the debug instructions in FastISel::sinkLocalValueMaterialization

// Collect all DBG_VALUEs before the new insertion position so that we can
// sink them.
SmallVector<MachineInstr *, 1> DbgValues;
for (MachineInstr &DbgVal : MRI.use_instructions(DefReg)) {
  if (!DbgVal.isDebugValue())
    continue;
  unsigned UseOrder = OrderMap.Orders[&DbgVal];
  if (UseOrder < FirstOrder)
    DbgValues.push_back(&DbgVal);
}

But it uses OrderMap.Orders[&DbgVal] to get the right location in the instructions.

If the goal is to make 'collectDebugValues' more generic, that function should be moved to MachineRegisterInfo and have the steps (1), (2) and (3).

@aprantl, @vsk: before submitting a new patch, I would like to hear your views.

lib/CodeGen/MachineInstr.cpp
2037 ↗(On Diff #161695)

You are correct. The clear() is not necessary.

But it uses OrderMap.Orders[&DbgVal] to get the right location in the instructions.

Do you have OrderMap readily available or would you need to compute it first?

If the goal is to make 'collectDebugValues' more generic, that function should be moved to MachineRegisterInfo and have the steps (1), (2) and (3).

That doesn't sound like a bad idea.

vsk added a comment.Aug 24 2018, 10:17 AM

@CarlosAlbertoEnciso thanks for investigating this and testing out a new way to collect debug values. Given the complexity of replacing the current algorithm, and that it's not strictly related to fixing MachineCSE, I'd recommend keeping the current algorithm (i.e not using MachineRegisterInfo for now). That will allow us to land a fix in tree soon and hopefully iterate on it.

CarlosAlbertoEnciso marked an inline comment as done.Aug 28 2018, 1:13 AM

Do you have OrderMap readily available or would you need to compute it first?

At the point where 'collectDebugValues' is called, OrderMap is not available. I need to compute it first.

If the goal is to make 'collectDebugValues' more generic, that function should be moved to MachineRegisterInfo and have the steps (1), (2) and (3).

That doesn't sound like a bad idea.

That would be a good improvement.

CarlosAlbertoEnciso added a comment.EditedAug 28 2018, 1:21 AM
In D50887#1212594, @vsk wrote:

@CarlosAlbertoEnciso thanks for investigating this and testing out a new way to collect debug values. Given the complexity of replacing the current algorithm, and that it's not strictly related to fixing MachineCSE, I'd recommend keeping the current algorithm (i.e not using MachineRegisterInfo for now). That will allow us to land a fix in tree soon and hopefully iterate on it.

I think is the best way to proceed right now, as the patch using the current algorithm is quite simple.

Once the patch is accepted, I would suggest to explore the replacement of the current algorithm to use MachineRegisterInfo and make 'collectDebugValues' a more general function. As @aprantl said, that doesn't sound like a bad idea.

Update the original patch, as the results from the investigation to replace the algorithm used by 'collectDebugValues', showed some additional complexities.

Replacing that algorithm, seems like a good idea, but not as part of the current issue.

Thanks to the reviewers for their valuable feedback.

vsk accepted this revision.Aug 28 2018, 10:48 AM

Thanks, LGTM. If you don't have commit access yet [1], I'd be happy to commit this on your behalf.

[1] https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

This revision is now accepted and ready to land.Aug 28 2018, 10:48 AM
In D50887#1216171, @vsk wrote:

Thanks, LGTM. If you don't have commit access yet [1], I'd be happy to commit this on your behalf.

[1] https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

Thanks for your offer to commit on my behalf.

I do have commit access but I am having some credential issues, that I am trying to fix. If the problem continues I can ask someone here at the office.

This revision was automatically updated to reflect the committed changes.