[PATCH] D68288: [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion

[Daniel Sanders via Phabricator via llvm-commits]

dsanders marked an inline comment as done.
dsanders added inline comments.


================
Comment at: llvm/trunk/utils/TableGen/GlobalISel/CMakeLists.txt:5
+
+llvm_add_library(LLVMTableGenGlobalISel OBJECT
+                 CodeExpander.cpp
----------------
thakis wrote:
> dsanders wrote:
> > thakis wrote:
> > > Out of interest, why is this an object library instead of a normal STATIC library?
> > I assume you're asking because some of the bots are failing. AFAICT it's the ones with older cmakes.
> > 
> > I went with an object library because it doesn't need to be an actual library. It's just a means to include them in the llbm-tblgen link. Switching to a STATIC library might be how I end up fixing it.
> No, I asked out of interest, like I said :)
> 
> Most libraries in LLVM don't need to be an actual library. It's just the usual unit of abstraction for a bunch of files. The index therein and their load semantics tend to be good for binary size.
Ah it was just coincidental timing then :-). Your question arrived in the middle of twenty or so bot failure emails about older cmake's not liking the object library.

> The index therein and their load semantics tend to be good for binary size.

I'm a bit curious about this as a static library (on Linux and macOS at least) is just the object files inside an 'ar' archive. I'm not aware of any functional difference (other than the existence of the static library) between linking a static library and linking the object files directly. Are you on a platform where that's not the case? or is there something about static libraries that I'm not aware of?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D68288