[PATCH] D126349: [TableGen] Remove code beads

[Min-Yih Hsu via Phabricator via llvm-commits]

myhsu added inline comments.


================
Comment at: llvm/lib/Target/M68k/M68kInstrInfo.cpp:622
+  if (OperandNo == MI->getNumExplicitOperands() - 1)
+    return Regex("[A-Z]+(8|16|32)[a-z]k$").match(InstrName);
+
----------------
You might want to handle tail call suffix ("_TC") as well (we're handling MachineInstr here, where tail call operators are still spelled out explicitly)


================
Comment at: llvm/utils/gn/secondary/llvm/utils/TableGen/BUILD.gn:15
     "CallingConvEmitter.cpp",
-    "CodeBeadsGen.cpp",
     "CodeEmitterGen.cpp",
----------------
RKSimon wrote:
> 0x59616e wrote:
> > myhsu wrote:
> > > Thanks for taking care GN as well!
> > I did some google, and realize that gn is a build system that can generate ninja build files.
> > 
> > Why do we have this, given that cmake can do the same thing ?
> Its used by some teams - the agreement was that it could be in the repo as long as everyone else doesn't have to worry about it :) Often you'll see auto? updates to the gn files after the equivalent cmakelists.txt file has been updated.
> I did some google, and realize that gn is a build system that can generate ninja build files.
> 
> Why do we have this, given that cmake can do the same thing ?

GN has some advantages over cmake in terms of generating Ninja. For instance, the reconfiguration speed after a GN file modification is much faster than that of a cmake file modification. But as Simon mentioned, currently in LLVM it's just an optional Ninja generation method for some teams to use for easier integration with their existing build environment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126349/new/

https://reviews.llvm.org/D126349