Adds IR level PGO Instrumentation options #1992
Conversation
chiragramani
changed the title
| if parsedOptions.hasArgument(.profileGenerate) { | ||
| commandLine.appendFlag("-fprofile-generate") | ||
| } |
There was a problem hiding this comment.
This feels like a bug to me. As I understand, Swift's -profile-generate flag does front-end instrumentation, and is different from Clang's -fprofile-generate.
There was a problem hiding this comment.
this behavior is existing in swift-driver today, and I’m a bit wary of changing it here because there may be tests and downstream flows that rely on it. This PR is primarily adding the new pieces, that said, if you feel it’s worth addressing this legacy behavior in the same PR, please let me know and I can look into it.
| public static let printTargetInfo: Option = Option("-print-target-info", .flag, attributes: [.frontend], metaVar: "<triple>", helpText: "Print target information for the given target <triple>, such as x86_64-apple-macos10.9") | ||
| public static let printZeroStats: Option = Option("-print-zero-stats", .flag, attributes: [.helpHidden, .frontend], helpText: "Prints all stats even if they are zero") | ||
| public static let profileCoverageMapping: Option = Option("-profile-coverage-mapping", .flag, attributes: [.frontend, .noInteractive], helpText: "Generate coverage data for use with profiled execution counts") | ||
| public static let profileGenerate: Option = Option("-profile-generate", .flag, attributes: [.frontend, .noInteractive], helpText: "Generate instrumented code to collect execution counts") |
There was a problem hiding this comment.
Should we change this help text to make it more clear this is front-end instrumentation?
| public static let printZeroStats: Option = Option("-print-zero-stats", .flag, attributes: [.helpHidden, .frontend], helpText: "Prints all stats even if they are zero") | ||
| public static let profileCoverageMapping: Option = Option("-profile-coverage-mapping", .flag, attributes: [.frontend, .noInteractive], helpText: "Generate coverage data for use with profiled execution counts") | ||
| public static let profileGenerate: Option = Option("-profile-generate", .flag, attributes: [.frontend, .noInteractive], helpText: "Generate instrumented code to collect execution counts") | ||
| public static let irProfileGenerate: Option = Option("-ir-profile-generate", .flag, attributes: [.frontend, .noInteractive], helpText: "Generate instrumented code to collect execution counts into default.profraw (overridden by LLVM_PROFILE_FILE env var)") |
There was a problem hiding this comment.
Can we also add irProfileGenerateEq like we do for the CS variant?
|
Just a friendly heads-up that new changes need to be added with this process: |
Yes, I’ve added |
Thank you for the heads-up! I’ll take a look and make sure to follow that process. |
This PR introduces two new instrumentation flags and plumbs them through to IRGen:
-ir-profile-generate- enable IR-level instrumentation.-cs-profile-generate- enable context-sensitive IR-level instrumentation.Context: https://forums.swift.org/t/ir-level-pgo-instrumentation-in-swift/82123
Open Questions (Reviewer Input Requested)
Naming:
Is
-ir-profile-generatea good flag name?-cs-profile-generatepairs nicely with Clang’s-fcs-profile-generate. However,-ir-profile-generatefeels closer to Clang's-fprofile-generatebut-profile-generatealready exists in Swift as a frontend level and not IR level. Should it stay as is, or is there a clearer alternative?PR separation strategy:
I also updated the auto-generated Options.swift file in this PR, I am aware its not supposed to manually updated and I have a Swift-side PR open here: Add IRPGO and CSIRPGO options to Swift swift#84335
.
Should I first land a separate PR in Swift adding only the new options, and then follow up with this PR for the Driver + IRGen functionality? My current assumption is that splitting them would help unblock this PR. Is that correct?