[lld] [CGData] LLD for MachO (PR #90166)

Ellis Hoag via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 12 13:49:28 PDT 2024


ellishg wrote:

> > `-fprofile-generate` supports modifiers like `%p, %h, %m, %t, and %c` to allow generating raw profile filenames based on the run instance. This is especially useful when we want to dump a bunch of raw profiles to a directory.
> > https://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
> > Do you think we should support something similar given that we can pass a directory to the clang frontend flag in #90304? If we build several binaries, we still want to disambiguate the `.cgdata` files, even if we want to dump them in the same directory. Maybe `%n` could expand to the binary name and `%b` could expand to some build number, which could be anywhere in the path. I'm also not sure if it's better to implement this in Clang or LLVM.
> 
> Thank you for the suggestion! I largely copied the Clang flags from IRPGO. Unlike IRPGO, which needs to handle many raw profile data files emitted by runtimes, here we deal with a single codegen data file at build time, similar to how a linker handles a single executable file. Therefore, I think the build system can easily configure this additional flag with the correct path for different binaries. So, I don't think there is a need to support a directory path or these modifiers for simplicity. I'm considering simplifying the Clang flag to avoid this confusion. What do you think?

I see. If we don't support writing profiles to a directory, then I don't think it's necessary to support these modifiers. I do, however, see the value in writing to a default file (`default.cgdata`) if no path is specified, similar to `a.out`. But I don't see the point in a user specifying a directory without specifying the filename.

https://github.com/llvm/llvm-project/pull/90166


More information about the llvm-commits mailing list