This implements the clang bits of https://reviews.llvm.org/D29308
I'm planning to use this to test the PGO inliner changes available only in the new pass manager.
I'm not very familiar with the clang driver so I'm not sure if this change is correct. PTAL (also suggestions on how to best test this are welcome).
Details
- Reviewers
xur chandlerc davidxl eraman llvm-commits - Commits
- rG945de43dbe2f: [PM] Add support for instrumented PGO in the new pass manager (clang-side)
rC294961: [PM] Add support for instrumented PGO in the new pass manager (clang-side)
rL294961: [PM] Add support for instrumented PGO in the new pass manager (clang-side)
Diff Detail
Event Timeline
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
823 | can you define a macro for the default profile file name to be shared? |
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
823 | Sure thing. I generally prefer a global const std::string (trying to avoid macros), is that the same to you? |
Thanks. I'll update a new version shortly. The llvm side of the patch is slightly more interesting as I made some assumptions (and I still am learning about PGO so I'm not entirely sure I put in the correct place in the pipeline)
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
823 | Global std::string objects are problematic due to the destructor. But we just recently added a handy string literal type to LLVM. =] |
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
63–65 | FWIW, this was part of AssemblyHelper initially. |
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
63–65 | Just for the records, not a clang bug, it's missing an out-of-line def (thanks zygoloid for pointing out) |
FWIW, this all looks good on my end. David, does this address your concern?
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
63–65 | As discussed in IRC, looks like we know how to sink this into the class now. |
FWIW, this was part of AssemblyHelper initially.
I thought that worked, instead I got a linker error (undefined reference to etc..)
I can't claim to be a C++ expert so I asked @Bigcheese and he pointed out this could actually be a bug in clang.