[llvm-bugs] [Bug 30798] New: VirtRegRewriter fails to set properties on BUNDLE instructions

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30798

            Bug ID: 30798
           Summary: VirtRegRewriter fails to set properties on BUNDLE
                    instructions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
          Assignee: unassignedbugs at nondot.org
          Reporter: mattias.v.eriksson at ericsson.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

In my out-of-tree back-end we run the register allocator after
bundling of instructions. The register allocator handles this mostly
fine, but I think there is a bug related to imp-use on subregister
definitions:

# *** IR Dump Before Virtual Register Rewriter ***:

     BUNDLE %vreg1<imp-def>
      * %vreg1:hiAcc<def> = ...

%vreg1 is a register pair which consists of hiAcc and loAcc. It is
allocated %a32, in which %a3 is hiAcc. After register allocation
imp-use is added on the bundled instruction but not on the BUNDLE
head.

# *** IR Dump After Virtual Register Rewriter ***:

     BUNDLE %a32<imp-def>
      * %a3<def> = ... %a32<imp-use>


I think %a32<imp-use> should be added to the BUNDLE head:

     BUNDLE %a32<imp-def>, %a32<imp-use>
      * %a3<def> = ... %a32<imp-use>


The relevant code is in VirtRegRewriter::rewrite():
      // Add any missing super-register kills after rewriting the whole
      // instruction.
      while (!SuperKills.empty())
        MI->addRegisterKilled(SuperKills.pop_back_val(), TRI, true);

      while (!SuperDeads.empty())
        MI->addRegisterDead(SuperDeads.pop_back_val(), TRI, true);

      while (!SuperDefs.empty())
        MI->addRegisterDefined(SuperDefs.pop_back_val(), TRI);

Should this be updated to also add the relevant flags on the bundle
head?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161026/12290a28/attachment.html>