[PATCH] D27807: [globalisel] Initialize RegisterBanks with static data. Part 1 of 2.
    Quentin Colombet via Phabricator via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Mon Dec 19 17:29:39 PST 2016
    
    
  
qcolombet requested changes to this revision.
qcolombet added a comment.
This revision now requires changes to proceed.
Hi Daniel,
Unless you can find a more elegant way for the intermediate step, I would push the change from BitSet to uint32_t* as part of the TableGen.
That being said, I think we could use intermediate steps:
1. Provide methods that perform the current add coverage logic, while producing the result in a dynamically allocated uint32_t
2. Gradually switch the dynamic array to static ones
3. Generate the static array with TableGen
Step #2 and #3 could be merged.
Cheers,
-Quentin
================
Comment at: include/llvm/CodeGen/GlobalISel/RegisterBank.h:38
   const char *Name;
-  unsigned Size;
+  DataTy Data;
   BitVector ContainedRegClasses;
----------------
What's the use for this indirection?
================
Comment at: include/llvm/CodeGen/GlobalISel/RegisterBankInfo.h:410
+  void setRegBankData(unsigned ID, const RegisterBank::DataTy &Data);
+  void setRegBankCoverage(unsigned ID, uint64_t CoveredClasses,
                           const TargetRegisterInfo &TRI);
----------------
What does CoveredClasses represent?
================
Comment at: lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:99
+void RegisterBankInfo::setRegBankCoverage(unsigned ID, uint64_t CoveredClasses,
                                           const TargetRegisterInfo &TRI) {
+  uint32_t Mask[] = {(uint32_t)CoveredClasses,
----------------
Why not directly use uint32_t *?
In particular, if we have target with more than 64 classes the API falls apart.
================
Comment at: lib/Target/AArch64/AArch64RegisterBankInfo.cpp:64
+                         (1ull << AArch64::tcGPR64RegClassID) |
+                         (1ull << AArch64::GPR64sponlyRegClassID),
+                     TRI);
----------------
I think I would rather have the change in representation be part of the TableGen change, because the intermediate step is painful to read and write IMO.
================
Comment at: lib/Target/AArch64/AArch64RegisterBankInfo.cpp:116
+          (1ull << AArch64::
+               QQQQ_with_qsub0_in_FPR128_lo_and_QQQQ_with_qsub3_in_FPR128_loRegClassID),
+      TRI);
----------------
Indeed, I don't want to check if this is correct :S
https://reviews.llvm.org/D27807
    
    
More information about the llvm-commits
mailing list