[PATCH] D20769: [IPRA] Interprocedural Register Allocation

[Mehdi AMINI via llvm-commits]

mehdi_amini added inline comments.

================
Comment at: include/llvm/CodeGen/PhysicalRegisterUsageInfo.h:54
@@ +53,3 @@
+  // and 1 means content of register will be preserved around function call
+  StringMap<std::vector<uint32_t>> RegMasks;
+};
----------------
MatzeB wrote:
> @Mehdi: I've seen you arguing for a stringmap here before, but I would argue that a reference to a compiler internal object would be more stable here, avoid string comparisons and also work with unnamed functions (not sure if that actually allowed in llvm, but I could see this happening for JITs...).
> 
> As to what object to use: MachineFunction* would be nice but I am not sure that would well as long as the MachineFunction gets created in the MachineFunctionAnalysisPass. So maybe tie it to the Functions GlobalObject for now and change it to MachineFunction* later when we switch to the new pass manager and hopefully can deal with MachineFunctions as a first-class object rather than an analysis.
I pointed a `StringMap` in order to not have the backend depends on the IR, now if you and Quentin thinks it is fine to go through a `GlobalVariable *`, I don't have strong feeling about it.
(and yes, unnamed global function are allowed)


http://reviews.llvm.org/D20769