[llvm-bugs] [Bug 26576] New: [GlobalISel] Generic MachineInstrs need a type but this increases the memory footprint of the related objects

[via llvm-bugs]

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

            Bug ID: 26576
           Summary: [GlobalISel] Generic MachineInstrs need a type but
                    this increases the memory footprint of the related
                    objects
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: GlobalISel
          Assignee: unassignedbugs at nondot.org
          Reporter: qcolombet at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

As r260558, we added a Type * field to the MachineInstr class. This field is
actually used only for generic MachineInstr and moreover, only during the
instruction selection process.
In other words, we negatively impact the memory footprint of the whole backend
pipeline for generic instructions that are used only at the beginning of such
pipeline.

The question is then, is it possible to have that information in a union or
something?
My initial thought was that we could have a derived class GenericMachineInstr
with additional information, but in practice it makes little to no sense since
generic MachineInstrs are likely turned into non-generic ones by just switching
the opcode. In other words, we don't want to go through the process of creating
a new, non-generic MachineInstr, object each time we do this switch. The memory
benefit probably is not worth the extra compile time.

Another option would be to keep the type of the MachineInstr in a side table.
This would induce an extra indirection though.

That being said, when we have the basic pipeline lay down, we will be able to
make measurements for the different option.

However, if you have ideas, please share!

-- 
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/20160211/30212fbc/attachment.html>