bogner wrote: First, I'll point out that using cl:opt to test passes is completely reasonable, but it doesn't necessarily mean that we can use those same options from clang to configure the pass. My concern is really that for options that really aren't target specific forwarding options to target specific cl::opt flags is untenable. Consider when we want to implement `/Fd` for SPIR-V - do we just have a switch in the driver over every target to pass a target specific `cl::opt` flag along?
Now in terms of what we're actually trying to accomplish I think we need to make some design considerations here. While `/Qembed_debug` could arguably map to a DirectX specific backend flag, mapping `/Fd` this way is very likely to be problematic, and I think we're setting ourselves up with technical debt with this approach. My comment about using a single option kind of missed this, but for context let me step back for a second: 1) `/Fd` specifies a file to put debug info in. This is not at all DirectX specific, and maps to a flag in cl.exe that does this for C/C++. Debug info is not included in the binary, but is only output in that separate file. 2) `/Qembed_debug` specifies that we should include the debug info in the binary (as normal). Without `/Fd` this is just a no-op, though DXC emits a warning telling you this is just doing what it would do anyway. 3) Both `/Fd` and `/Qembed_debug` together means we want the debug info to be emitted in the binary (as usual) and also emitted to a separate file. Let's talk about these three modes separately. - For (1), this is very much like `-split-dwarf`. IMO, we should probably generalize `MCTargetOptions::SplitDwarfFile` to `SplitDebugFile` and implement `/Fd` generally. Doing this in a "this just forwards to a DirectX target option" way is adding tech debt, and ignores the fact that this option is much more general than just DirectX. Supporting this improves MSVC compatibility and also helps with what to do for things like HLSL targeting SPIR-V. - For (2) without (3), this literally does nothing. We should simply ignore this with the caveat that maybe we should match DXC's kind of useless warning. This can definitely be frontend only though. - For (3) we have an unusual case. Consider this implementation strategy though: what if the frontend simply generated the module with debug info, and then extracted the debug info into a separate file? This avoids generating the same debug info twice, can be done with something like an `objcopy` invocation by the driver, and guarantees what we're getting matches the case where we don't have a separate step to re-create debug info. https://github.com/llvm/llvm-project/pull/204166 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
