[ScheduleDAG] Fix bug in check for use of dead defs
Needs RevisionPublic

Authored by dstuttard on Jun 30 2017, 8:26 AM.

Details

Reviewers
MatzeB
Summary

Was asserting when checking for uses of dead defs as it wasn't allowing for
subregisters
This was shown in the case (for AMDGPU) where:

%vreg79:sub3<def,dead,tied3> = V_MAC_F32_e32 %vreg914<undef>, %vreg901,
%vreg79:sub3<tied0>, %EXEC<imp-use>;

and vreg79:sub0 vreg79:sub1 are subseqently used, but sub3 is not - firing the
assertion incorrectly.

Modified the check to make sure that it only checks for uses of the same lane.

dstuttard created this revision.Jun 30 2017, 8:26 AM

I do have a reproducer for this (a .ll test). I've attempted to turn this into a .mir test, but it is too fragile to allow me to change the target specific intrinsics to something generic (required in order to print out the .mir).
Hopefully, the check is an obvious omission and an easy one to approve?
If not I'll see if I can create a smaller regression for it - but I've already spent quite a lot of time attempting to do this.

MatzeB requested changes to this revision.Jul 19 2017, 5:40 PM

Testcase? It seems that your change wants to allow the following:

vreg4:sub0<def, dead> = ...
...
  = use vreg4:sub1

This is not legal! The dead modifier is about the full vreg not just about the sub0 part defined. (-verify-machineinstrs should also lead to such inputs getting rejected).

This revision now requires changes to proceed.Jul 19 2017, 5:40 PM

Testcase? It seems that your change wants to allow the following:

vreg4:sub0<def, dead> = ...
...
  = use vreg4:sub1

This is not legal! The dead modifier is about the full vreg not just about the sub0 part defined. (-verify-machineinstrs should also lead to such inputs getting rejected).

Are you sure about this? This doesn't seem logical to me, plus I've been working on the assumption - perhaps incorrect - that this isn't the case :)
If so, then the bug here is more about the full vreg being tagged as dead when it isn't.

As for a test case - I do have a reproducer, but I couldn't convert it to a .mir test (which I think would be best) and as a .ll level test it seems a little bit fragile (as well as quite large, even after using bugpoint to reduce). If we get to the bottom of the issue (if it isn't what I've changed), then I'll spend some more time seeing if I can generate something suitable.