It's a goal, but it's not a priority because there's so much else going on, and we haven't even fully scoped it. It's mostly not the build outputs that matter but everything else, particularly the search paths. I've talked about this some with @adrian-prantl, @ddunbar, and email@example.com (JIRA User), but we've been focusing on other debugging improvements in the meantime.
Unassigning from myself, since I haven't found the time for some number of weeks to really take this on.
For the purposes of the macOS platform, normalizing the DWARF information in a dSYM bundle for Swift source code, the preferred flag to imitate would be -fdebug-prefix-map , rather than -fdebug-compilation-dir.
Ideally it would be mapping all paths from a certain build root to a normalized token like ".", which could be remapped through lldb's settings target.source-map in an lldbinit file or a DBGSourcePathRemapping described in a UUID properly list embedded within each of the dSYM bundles.
At least, that's how I think this problem should be handled.
The Clang implementation of -fdebug-prefix-map handles this by replacing path substrings in the emitted debug information. I'm not yet aware of what else the Swift compiler frontend would need to do to handle this similarly.
The implementation of -debug-prefix-map was merged in #17665
Remapping just the debug info paths, but not any search paths/ClangImporter options in swiftmodules, appears to be sufficient to make LLDB do the right thing for a standalone binary (one including .o files from one or multiple modules statically linked together along with all their ASTs via -add_ast_path, and even if those ASTs did not serialize debugging options). This is a reasonable first step; more complicated scenarios (involving, say, dynamic frameworks) may require more attention but we can explore those incrementally more easily with this initial implementation in place.