[PATCH] MIR Serialization: Serialize the UsesPhysRegMask from machine register info.

[Duncan P. N. Exon Smith via llvm-commits]

> On 2015-Aug-05, at 16:26, Alex L <arphaman at gmail.com> wrote:
> 
> 
> 
> 2015-08-05 14:17 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>:
> 
> > On 2015-Jul-30, at 16:47, Alex L <arphaman at gmail.com> wrote:
> >
> > Hi,
> >
> > This patch serializes the UsesPhysRegMask register mask from the machine register
> > information class. The mask is serialized as an inverted 'calleeSavedRegisters' mask
> > to keep the output minimal. It uses the following syntax:
> >
> > calleeSavedRegisters: [ '%bh', '%bl', '%bp', '%bpl', '%bx', '%ebp', '%ebx',
> >                         '%rbp', '%rbx', '%r12', '%r13', '%r14', '%r15',
> >                         '%r12b', '%r13b', '%r14b', '%r15b', '%r12d', '%r13d',
> >                         '%r14d', '%r15d', '%r12w', '%r13w', '%r14w', '%r15w' ]
> >
> > As you can see, the sub registers are included in this mask as well.
> >
> > This patch also allows the MIR parser to infer this mask from the register mask
> > operands if the machine function doesn't specify it.
> >
> > Cheers,
> > Alex
> > <0001-MIR-Serialization-serialize-the-UsesPhysRegMask-from.patch>
> 
> > From ca446d1f7a90691ffcc0c1ac16855e5b0eb7a9d0 Mon Sep 17 00:00:00 2001
> > From: Alex Lorenz <arphaman at gmail.com>
> > Date: Thu, 30 Jul 2015 16:37:25 -0700
> > Subject: [PATCH] MIR Serialization: serialize the UsesPhysRegMask from
> >  register info
> >
> > ---
> >  include/llvm/CodeGen/MIRYamlMapping.h              |  2 +
> >  include/llvm/CodeGen/MachineRegisterInfo.h         |  4 +
> >  lib/CodeGen/MIRParser/MIRParser.cpp                | 31 ++++++++
> >  lib/CodeGen/MIRPrinter.cpp                         | 12 +++
> >  .../MIR/X86/used-physical-register-info.mir        | 89 ++++++++++++++++++++++
> >  5 files changed, 138 insertions(+)
> >  create mode 100644 test/CodeGen/MIR/X86/used-physical-register-info.mir
> >
> > diff --git a/lib/CodeGen/MIRPrinter.cpp b/lib/CodeGen/MIRPrinter.cpp
> > index f34cef7..9ce7e19 100644
> > --- a/lib/CodeGen/MIRPrinter.cpp
> > +++ b/lib/CodeGen/MIRPrinter.cpp
> > @@ -213,6 +213,18 @@ void MIRPrinter::convert(yaml::MachineFunction &MF,
> >        printReg(I->second, LiveIn.VirtualRegister, TRI);
> >      MF.LiveIns.push_back(LiveIn);
> >    }
> > +  // The used physical register mask is printed as an inverted callee saved
> > +  // register mask.
> > +  const BitVector &UsedPhysRegMask = RegInfo.getUsedPhysRegsMask();
> > +  if (UsedPhysRegMask.none())
> > +    return;
> 
> Will this cause a problem on the parsing side?  In particular, won't the
> reader infer "the default set" here?  To put it another way, how do you
> express in MIR that no registers should be marked callee-saved?
> 
> So, this none condition is triggered only when the machine function
> doesn't have any register mask operands. Because of that, we don't
> really want to serialize it as this mask isn't really active in this case.
> And the parser will try to infer it when parsing it back in this case,
> but I think it's better if it will do that - if the MIR file wasn't modified
> the result mask will stay exactly the same as it was before it was
> serialized, and otherwise, if the user modified the MIR file and added
> some instructions with register mask operands then the parser will
> compute the mask correctly.
> 
> But I have updated the patch anyway with a related feature - so now the
> parser won't infer the mask when you specify an empty array of
> callee-saved registers. Although I'm not sure if it's really that useful,
> you wouldn't normally want to have an empty array here anyway.
>  
> 
> > +  for (unsigned I = 0, E = UsedPhysRegMask.size(); I != E; ++I) {
> > +    if (!UsedPhysRegMask[I]) {
> > +      yaml::FlowStringValue Reg;
> > +      printReg(I, Reg, TRI);
> > +      MF.CalleeSavedRegisters.push_back(Reg);
> > +    }
> > +  }
> >  }
> >
> >  void MIRPrinter::convert(ModuleSlotTracker &MST,
> 
> 
> <0001-MIR-Serialization-serialize-the-UsesPhysRegMask-from.patch>

Okay, LGTM.