Support -embed-bitcode and -driver-print-bindings #101
Conversation
| // -embed-bitcode only supports a restricted set of flags. | ||
| commandLine.appendFlag(.target) | ||
| commandLine.appendFlag(targetTriple.triple) | ||
|
|
||
| // Enable address top-byte ignored in the ARM64 backend. | ||
| if targetTriple.arch == .aarch64 { | ||
| commandLine.appendFlag(.Xllvm) | ||
| commandLine.appendFlag("-aarch64-use-tbi") | ||
| } | ||
|
|
||
| // Handle the CPU and its preferences. | ||
| try commandLine.appendLast(.targetCpu, from: &parsedOptions) |
There was a problem hiding this comment.
A bunch of this is repeated fromaddCommonFrontendOptions. Can you factor some of it our so there's less duplication here?
There was a problem hiding this comment.
So there is some duplication here, but I don't know how much I can factor out without changing the order of the arguments (That shouldn't really matter, but there are probably some lit tests that rely on the current ordering.
The interesting part from addCommonFrontendOptions is:
switch compilerMode {
case .standardCompile, .singleCompile, .batchCompile, .compilePCM:
commandLine.appendFlag(.target)
commandLine.appendFlag(targetTriple.triple)
case .repl, .immediate:
if parsedOptions.hasArgument(.target) {
commandLine.appendFlag(.target)
commandLine.appendFlag(targetTriple.triple)
}
}
if let variant = parsedOptions.getLastArgument(.targetVariant)?.asSingle {
commandLine.appendFlag(.targetVariant)
commandLine.appendFlag(Triple(variant, normalizing: true).triple)
}
// Enable address top-byte ignored in the ARM64 backend.
if (targetTriple.arch == .aarch64) {
commandLine.appendFlag(.Xllvm)
commandLine.appendFlag("-aarch64-use-tbi")
}
// Enable or disable ObjC interop appropriately for the platform
if targetTriple.isDarwin {
commandLine.appendFlag(.enableObjcInterop)
} else {
commandLine.appendFlag(.disableObjcInterop)
}
// Handle the CPU and its preferences.
try commandLine.appendLast(.targetCpu, from: &parsedOptions)The switch is fine, because we don't have backend jobs for repl and immediate builds, but would have to move these out of order.
if let variant = parsedOptions.getLastArgument(.targetVariant)?.asSingle {
commandLine.appendFlag(.targetVariant)
commandLine.appendFlag(Triple(variant, normalizing: true).triple)
} // Enable or disable ObjC interop appropriately for the platform
if targetTriple.isDarwin {
commandLine.appendFlag(.enableObjcInterop)
} else {
commandLine.appendFlag(.disableObjcInterop)
}Looking at this further. Is there any reason that the embed-bitcode job doesn't use the targetVariant parameter. Seems like it should, but the c++ driver doesn't.
There was a problem hiding this comment.
Hmm. I see what you mean. We can keep it like this, and maybe there’s some future refactoring we can do. I worry about maintainability when we’re doing the same argument translation in several places.
Regarding -target-variant, yes, I think we should pass it through for bitcode compilation. It gets embedded in the binary. This is probably a bug in the C++ driver
There was a problem hiding this comment.
Should I add the -target-variant here?
There was a problem hiding this comment.
Yes, please add the -target-variant
| var jobOutputs: [TypedVirtualPath] = [] | ||
| let job = try compileJob(primaryInputs: primaryInputs, outputType: .llvmBitcode, allOutputs: &jobOutputs) | ||
| jobs.append(job) | ||
| for input in job.outputs.filter({ $0.type == .llvmBitcode }) { |
There was a problem hiding this comment.
This is really nice and clean, thanks!
|
@swift-ci test |
|
@cltnschlosser Mind if I go ahead and merge this? The |
Yep, sounds good |
Driver/verify-debug-info.swift(dysm at wrong name)Driver/multi-threaded.swiftare fixed (Still some tests there "failing" because parsable output json is in different order)Driver/embed-bitcode.swifttests are fixed except one. Driver jobs are printed in different order.In this case the merge module job gets printed before the backend job. For all other tests the merge module job is last. Not sure what is effecting the print order in c++ driver.