[llvm-dev] Not increasing SDNodeOrder for llvm.dbg.value to avoid different scheduling?

[Mikael Holmén via llvm-dev]

Hi,

We've noticed a case where ScheduleDAGRRList behaves differently when 
there are llvm.dbg.value present.

When building the selection dag, the SDNodeOrder field is increased for 
every visited instruction, including calls to llvm.dbg.value. The 
SDNodeOrder is saved in each SDNode in the IROrder field.

Then in ScheduleDAGRRList.cpp, the IROrder is used, e.g via 
bu_ls_rr_sort::operator() (via BURRSort, via SPQ->getNodeOrdering) 
affecting the scheduling order.

This can result in different scheduling order depending on if there 
happens to be calls to llvm.dbg.value present in the code or not.

If we only increase the SDNodeNumber for non llvm.dbg.value/declare 
instructions then this goes away:

+  // Increase the SDNodeOrder if dealing with a non-debug instruction
+  if (!isa<DbgValueInst>(I) && !isa<DbgDeclareInst>(I))
     ++SDNodeOrder;

However, I've no idea if this change is fundamentally breaking how the 
SDNodeOrder stuff is supposed to work.

Does this seem reasonable?


I noticed that one test case failed due to the change above.

For test/DebugInfo/X86/Output/subregisters.ll I got a few changes in the 
output which I suppose is a significant regression:

27c27
<       DW_AT_location  DW_FORM_block1
---
 >       DW_AT_location  DW_FORM_data4

[...]

109c108
<                   DW_AT_location [DW_FORM_block1]     (<0x01> 55 )
---
 >                   DW_AT_location [DW_FORM_data4]      (0x00000000)

[...]

115,116c114
< 0x00000055:     DW_TAG_variable [4]
<                   DW_AT_location [DW_FORM_data4]      (0x00000000)
---
 > 0x00000057:     DW_TAG_variable [4]

[...]

178,180c176,178
< 0x00000000: Beginning address offset: 0x0000000000000002
<                Ending address offset: 0x0000000000000014
<                 Location description: 54 93 04
---
 > 0x00000000: Beginning address offset: 0x0000000000000000
 >                Ending address offset: 0x0000000000000009
 >                 Location description: 55

Any thoughts on this?

Thanks,
Mikael