[PATCH] D20769: [IPRA] Interprocedural Register Allocation

Matthias Braun via llvm-commits llvm-commits at lists.llvm.org
Tue May 31 18:07:37 PDT 2016


I know some of the issues are more a matter of personal preference than there being one true way. I just felt I should point out how I feel about them before people start writing them down as the one true way in the coding conventions :) I will of course not block the patches if we end up with a different style here.

> On May 31, 2016, at 6:02 PM, Mehdi AMINI <mehdi.amini at apple.com> wrote:
> 
> mehdi_amini added inline comments.
> 
> ================
> Comment at: lib/Target/X86/X86RegUsageInfoPropagate.cpp:93
> @@ +92,3 @@
> +}
> +
> +bool RegUsageInfoPropagationPass::runOnMachineFunction(MachineFunction &MF) {
> ----------------
> MatzeB wrote:
>>> for(auto &MBB : MF) {
>>> for(auto &MI : MBB) {
>> 
>> Please do not use `auto` in contexts where it is not obvious what type it represents. It is friendlier for the readers to use `MachineBasicBlock &MBB` and `MachineInstr &MI` here.
>> 
> I feel  that it is clearly obvious that `MI` is a `MachineInstr` when reading `for(auto &MI : MBB) {`, I'll be explicit if it was something else. But I won't pick this fight :)
> 
> ================
> Comment at: lib/Target/X86/X86RegUsageInfoPropagate.cpp:114
> @@ +113,3 @@
> +        auto updateRegMask = [&](StringRef FuncName) {
> +          const auto *RegMask = PRUI->getRegUsageInfo(FuncName);
> +          if (RegMask) { // else skip optimization
> ----------------
> MatzeB wrote:
>> This does not seem complicated enough to me to warrant a lambda. What about:
>> 
>> 
>> ```
>> const char *FuncName = nullptr;
>> if (Operand.isGlobal()) {
>>  Name = Operand.getGlobal()->getName();
>> } else if (Operand.isSymbol()) {
>>  Name = Operand.getGlobal()->getName();
>> }
>> if (FuncName != nullptr && RegMask) {
>>  setRegMask(MI, &(*RegMask)[0]);
>>  changed = true;
>> }
>> ```
> I guess it is a matter of personal style, I'd try to avoid this construct when possible, but I don't really care here.
> 
> 
> http://reviews.llvm.org/D20769
> 
> 
> 



More information about the llvm-commits mailing list