This will handle expansion of C++ fragments in the declarative combiner
including custom predicates, and escapes into C++ to aid the migration
effort.
Details
- Reviewers
bogner volkan - Commits
- rG18350af15930: [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion
rL373651: [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion
rGeb27b5de538b: [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion
rL373551: [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38833 Build 38832: arc lint + arc unit
Event Timeline
llvm/utils/TableGen/GlobalISel/CMakeLists.txt | ||
---|---|---|
6 | Nit: extra whitespace |
llvm/trunk/utils/TableGen/GlobalISel/CMakeLists.txt | ||
---|---|---|
5 ↗ | (On Diff #222946) | Out of interest, why is this an object library instead of a normal STATIC library? |
llvm/trunk/utils/TableGen/GlobalISel/CMakeLists.txt | ||
---|---|---|
5 ↗ | (On Diff #222946) | 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. |
llvm/trunk/utils/TableGen/GlobalISel/CMakeLists.txt | ||
---|---|---|
5 ↗ | (On Diff #222946) | 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. |
llvm/trunk/utils/TableGen/GlobalISel/CMakeLists.txt | ||
---|---|---|
5 ↗ | (On Diff #222946) | 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.
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? |
Nit: extra whitespace