With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20%
Details
Diff Detail
- Build Status
Buildable 9610 Build 9610: arc lint + arc unit
Event Timeline
Documentation needs to be added to clang/docs/ClangCommandLineReference.rst .
There probably also needs some kind of testing for the option processing: see clang_f_opts.c
docs/ClangCommandLineReference.rst | ||
---|---|---|
176 ↗ | (On Diff #112496) | If the sample profile is accurate, callsites without profile samples are marked as cold. Otherwise, ..., |
include/clang/Driver/Options.td | ||
593 | un-sampled callsites --> callsites without profile samples |
docs/ClangCommandLineReference.rst | ||
---|---|---|
173–180 ↗ | (On Diff #112574) | This is a generated file; please don't modify it by hand. |
include/clang/Driver/Options.td | ||
590 | We generally try to group similar options together under a common prefix. Would -fprofile-sample-accurate work here? | |
592–594 | HelpText should be a very brief string that can be included in a one-line description of the flag for --help. Longer text for inclusion in the option reference should be in a DocBrief<{blah blah blah.}>. Also, it seems to me that this help text doesn't actually say what the option does. Does this request that accurate sample profiles be generated, or specify that an accurate sample profile was provided, or what? Suggestion: HelpText<"Specifies that the sample profile is accurate">, DocBrief<{Specifies that the sample profile is accurate. If the sample profile is accurate, callsites without profile samples are marked as cold. [...same as current reference documentation text...]}> |
test/CodeGen/thinlto-profile-sample-accurate.c | ||
---|---|---|
2–4 | test/CodeGen tests should generally not run the optimizer; these tests are intended to check that the correct IR is produced by CodeGen prior to any optimization. So: we should have a unit test that the IR produced by Clang contains the attribute in the right place (prior to any LLVM passes running), here in test/CodeGen. It seems fine to me to have an end-to-end integration test in addition to that (but not instead of it); we haven't yet established a systematic organization for those tests, but putting it in test/Integration for now will make it easier to find in the future when we work that out. |
We generally try to group similar options together under a common prefix. Would -fprofile-sample-accurate work here?